摘要: 模塊的可擴展性是模塊設計時需要重點考慮的非功能特性，對于框架而言，擴展性的設計則更加的重要，框架需要通過不斷的擴展來充實其基礎設施，構成真正的應用系統。
模塊的擴展主要有兩種，一種為擴充功能的擴展，另一種為覆蓋性質的擴展，當然，本質上而言是可以把這兩者進行合并的。
在模塊的擴展上Eclipse的擴展點的設計方式無疑是支撐模塊可擴展的經典設計方法，到現在為止仍然是如此，基于Eclipse的擴展點的設計無論是對于擴充功能的擴展還是覆蓋性質的擴展都支持的非常好，這個經典的設計也是RCP得到那么多client side app的原因之一，盡管OSGi中并沒有定義這方面的規范，但做為OSGi R4的RI的Equinox考慮到更好的支撐Bundle的擴展就引入了Eclipse的擴展點的設計，在現在的Equinox中我們仍然可以基于Eclipse的擴展點的方式來支撐模塊的可擴展性。
但是否有別的方法呢？一定需要Eclipse的擴展點的方式嗎？其實個人覺得基于OSGi的Service就已經天然的構成了一種可擴展的設計，為什么這么說呢？
閱讀全文
摘要: 在企業應用中，持久化無疑是其中非常重要的一環，盡管OSGi的規范中也有負責持久數據、屬性的服務規范，但對于企業應用而言那些顯然是不夠的，這里就以目前Java界流行的Hibernate為例來看看如何集成Hibernate到OSGi中，使得我們能夠很簡單在OSGi中使用Hibernate進行持久化。
閱讀全文
摘要: OSGi越來越風行了，得到的關注越來越多，這本來是好事，但聽到的越來越多的聲音都是認為OSGi對于B/S、企業應用支持的太不夠，怎么說呢，這些聲音挺好，至少說明發出這些聲音的人肯定是想過將OSGi應用到自己的項目/產品中去，雖然這是好的，但我覺得更多的原因還是很多的人都習慣的以一種框架的觀點去看OSGi，這對于OSGi而言或多或少有些不公平，為什么這么說呢？
閱讀全文
摘要: 最近一段時間，OSGi這個詞在業界出現的頻率已經越來越高，其受關注的程度也已經在大幅度的增長，當然，這其中不可否認OSGi聯盟、Eclipse、IBM等的推廣，但這主要當然還是得益于OSGi在規范的模塊化以及動態化的管理的領先優勢，但也會發現，很多廠商以及很多人對于OSGi仍然處于觀望階段，這主要還是因為OSGi在企業應用上目前尚無太多案例的原因，但OSGi就真的不適合企業應用了嗎，還是別的原因讓這么多的廠商、這么多的人對OSGi只是處于觀望的階段呢，應該說，主要原因應該是OSGi目前對于企業應用缺少足夠的基礎設施，OSGi聯盟顯然認識到了OSGi在企業應用上的不足，9月11日OSGi聯盟對外正式宣布了EEG(EEG的成員包含了IBM、BEA等各大廠商)的成立；而Spring與OSGi的結合更是很好的推動OSGi進入企業應用。那么，就現在的OSGi規范來看，它離企業應用到底還有多遠呢：
閱讀全文
摘要: 個人覺得設計人員可以分為四種類型：模塊設計人員、框架設計人員、專業領域設計人員、系統設計人員，這四種類型的設計人員并沒有什么絕對的誰強誰弱，只能說各有千秋吧，但一定程度上來講，四種類型之間還是存在著一些關聯，來看看這四類設計人員的專注點和關聯吧：
閱讀全文
摘要: 規范的模塊化開發是需要OSGi的重要理由之一，模塊化的開發方式一直就是現在的主流開發方式，但業界卻一直缺乏這樣的標準，當然，如果java本身具備這樣的標準自然就更好了，那么大家就會很自然的以同樣的方式去設計、開發和部署模塊，但目前java暫時還沒有這樣的標準，雖然之前的JSR 277(Java Module System)的目標是制定這樣的標準，但由于該標準制定完后并沒有得到業界和各大廠商的認可，所以基本上沒起到什么作用，而現在JSR 291的認可則更是觸動了它，目前的情況看下去，OSGi成為下一個版本的Java Module System JSR只是時間的問題而已，整個業界能夠采取統一的方式進行模塊的設計、開發是非常重要和有意義的事，這也是OSGi得到IBM等大公司支持的重要原因之一，說了這么多背景性質的話后開始來看看OSGi是如何規范化模塊的開發的：
閱讀全文
摘要: 在OSGi的官方網站的blog上Peter Kriens(OSGi主席)貼了一篇關于Spring and OSGi的blog，呵呵，peter在blog里寫的還真不客氣，直接說以前只是聽說過spring而已，但基本上沒任何了解，不過peter畢竟是高人，稍微看了后便準確的點出了spring的兩個核心：解決依賴和組裝的配置方式以及POJO的動態增強，Peter在blog里提及到在OSGi R5中將考慮如何讓現有系統無需改動移植至OSGi平臺中，這點非常令人興奮，不過R5估計還早，最近OSGi R4.1倒是準備release了，目前還沒得到關于4.1對比4的改進的信息，在blog中，peter也提及他認為目前Spring and OSGi的很多實現過于繁瑣，于是之前他和spring-osgi的幾個人員碰面重新考慮了這塊的設計，這可是非常好的事，OSGi的開發人員的視角和企業應用的開發人員的視角確實會有很大的不同，兩者的碰撞還是能產生不少火花的，通過那次討論，Peter認為OSGi的服務注冊/尋找機制可以很好的和spring的applicationContext機制做結合，他覺得現在這樣的改
閱讀全文
摘要: 盡管這只是一個小項目，耗時也很短，但個人覺得這個項目的整個過程還是值得回顧的，項目雖小，五臟俱全，項目經歷了兩個小的迭代，迭代過程中經歷了典型的需求調研、設計、開發&重構、集成測試過程，采用了現場客戶、TDD等實踐，這里就以第一迭代來對這個項目的過程做些總結：
1、迭代版本的頻繁發布能很好的建立客戶方對于系統的信心；
2、結合真實系統的調研能夠更加準確的挖掘(引導)客戶的需求；
3、簡單而完整的設計過程和TDD能保證開發較好的完成；
4、把握設計的尺度，依靠重構來不斷的提升設計。
5、提升系統的交互對于客戶是直接而明顯的幫助。
閱讀全文
摘要: 表單是我們在實現應用時常用的，通常情況下多數的應用系統對于用戶而言就是在于表單打交道，所以提升表單的交互能力是非常重要的一個環節，當然，交互其實很多時候和業務都是有關系的，就如很多業務表單需要的是快速錄入的方式，這個時候如回車添加行、Tab快速切換到相應的域上都是非常重要的，在網上查了一下，沒找到一個完整的交互性質的表單的Demo，非常的希望css高手們能動手搞一個這樣的東西，這樣以后大家就方便了，由于在現在的一個項目中用到了，就把自己做的一個具備了一定能力的交互表單放到網上，希望有高手能基于這個或者自己做一個能作為以后做表單時可參考的對象，在這個交互表單中，對于交互性主要提供了這么一些：
1、表單進入域時的即時提醒
2、回車增加行
3、星級評分
4、域值非法的提示
下載地址：http://www.aygfsteel.com/Files/BlueDavy/richform.rar
閱讀全文
摘要: 簡單的談談交互中重要菜單和工具欄按鈕；
備忘javascript清空表格中行的問題；
備注動態創建的radio按鈕無法選中的問題。
閱讀全文