隨筆分類(103)

    昨天看到《精通EJB3.0》的中文版出來了，雖然早就在預料之中了，不過多少還是有一點想法的，終于第一本 EJB 3.0 的書正式出來了，對目前 EJB 3.0 的追逐總歸是有了點方向，但我仍然感覺，EJB 3.0 不可能像 EJB 2.0 那樣火了，Java 世界已經進入了多元化時代，Spring 已經逐步的蠶食了 EJB 說占有的份額，用其簡單靈活的配置吸引了無數人的眼光，從另外一方面來說，標準的東西畢竟是標準，從制定到實現的周期比較長，如果中間出現了新的需求，一些問題，都需要等到下一個標準中去實現，而開源的就比較靈活了，有問題可以隨時調整，所以會帶給大家更為 agile 的感覺，不過對于大公司大項目而言，他們并不希望這樣的靈活性，他們需要的是風險小，穩定，所以 EJB 3.0 對于一些大型的企業應用來說依然需要的是 EJB，因為有 IBM 和 BEA 這樣大公司的支持了，不過自從五月份 JavaEE 5 規范正式定稿，這兩大公司都沒有拿出真正的 EJB 3.0 的產品出來，倒是 JBoss 在標準出來后很快就拿出了可用的產品，這樣也可以看出來，IBM 和 BEA 沒有像過去幾年對于 EJB 2.0 那樣的重視了，他們關注的是 SOA 的市場，畢竟 SOA 在 EAI 方面比 JavaEE 強了很多。

    對于分布式對象領域，EJB 3.0 還是有著不錯的競爭優勢的，畢竟這是他的傳統優勢，在群里面和大家聊天的時候，寒江也提到過用 RCP + EJB 3.0 作為方案，其實這也是一套不錯的應用方案。

    EJB 3.0 比 EJB 2.0 確實要輕了很多，但并沒有給我們太多的驚喜，因為 EJB 3.0 給我們帶來的大部分新鮮都已經被 Spring 和 Hibernate 捷足先登了，我個人也是比較喜歡 Spring 和 Hibernate 來做項目，畢竟用起來會更加的靈活，更加的強大，特別是新版的 Spring 和 Hibernate 同時都支持了 JPA 的標準，又一次的在 JavaEE 應用上和 EJB 3.0 展開了下一輪的競爭，一切都好，就看你怎么選擇，我選擇的是 Spring + Hibernate，或許更加熟悉一些又或許更加輕量，更加 agile。

    一直從dearbook創辦起就在 dearbook 買書直到現在，已經成為了鉆石VIP會員了，經歷了 dearbook 發展中的種種，不過說起來 dearbook 的服務確實不像其標語中說標榜的"第二書店，第一服務"，從我這么多年和他們打交道的經驗來說，服務確實很難讓人滿意。

    過去一開始的時候，都是采用在網上選書，然后郵局匯款，發郵局包裹的方式，效率很低，也很麻煩，每次總是要往郵局跑兩次，最大的問題是，網上列出來的書，往往是不一定有貨的，有一次買書，選了一堆書最后發現就一本書有貨，最后拿到手的只有那一本書，很是郁悶，這樣就余下了一些錢在 dearbook，然后又用這些錢繼續去買其它的書，最后在升級會員的時候，這些余款購買的書又沒有記入積分中，升級的時候就差了這么幾分，最后催了好幾次才把自己會員資格提高。

    隨著和當當網合作以后，付款和收貨方面確實有很大的改善，付款直接用網上銀行，直接送貨上門，都大大的提高了我買書的興趣，不過 dearbook 網站系統很不爭氣，頻頻出現問題，首先發現一個明顯的 bug 就是在收藏夾里刪除一些書籍的時候，收藏夾就變亂了，都是一些莫名其妙的書，再打開一下這個頁面就好了。接著是在和 CSDN Passport 整合的時候，收藏夾里的書徹底丟光了，而這時候沒有人告訴我怎么回事。

    在與當當網的合作中dearbook 的積分系統也頻頻出現問題，當當網是用 Email 賬戶登錄的，dearbook 積分系統也是用 Email 賬戶登錄的，當我修改了當當網的 Email 以后，dearbook 積分系統也換成了新的 Email，但原有 Email 對應積分沒有轉到新的 Email 帳號上來，打電話去問，答曰，沒有提供合并積分的功能，于是一堆積分就泡湯了。

    最近積分比較多，在 dearbook 換了兩本書，最后收包裹的時候，只收到一本書，覺得奇怪，打電話去問，才把第二本書給重新寄過來，浪費了我幾分鐘的電話費。

    這次 dearbook 又心血來潮的要把 D幣積分轉換為 C 幣，因為過去在兩個Email 賬戶上都是有積分的，所以想轉換到同一個賬戶上，結果當我在 CSDN 上修改了 Email 地址后，卻發現我過去的積分就消失了，很是郁悶。昨天發了郵件，今天打了電話，到現在也沒有人給我答復，看了一下賬戶里的 C 幣，還是不對。

關于敏捷問題

周末聽 rocket 介紹了一些來自 thoughtworks 關于敏捷的一些思想，同時也引發了大家的一些思考和討論。從一種角度來看， Agile 體現了一種軟件開發最根本的問題，就是由人在一定的時間內開發出高質量的軟件，Agile 更加注重人在整個活動里的作用，而傳統的瀑布模型中，似乎更加注重文檔等，也就是我過去所在的公司，一切開發都由文檔驅動，在這樣的情況下，團隊中每個人都是可以被替代的，從某種意義上來說，降低了軟件開發的風險，但是效率卻很難提高。而 Agile 注重的一個方面就是 pair，通過拉近人與人之間的具體來加快信息在團隊中的流轉速度，使信息像水流一樣源源不斷的流動，這樣在 change 發生時，能夠得到更快的響應，而瀑布模型則需要慢慢的由文檔傳播開來，傳遞速度和面都比較有限。

雖然 thoughtworks 給了我們一個極具誘惑的 Agile 果子，某種意義上來說是建立在他們公司利益基礎上的，真正的去做 Agile 需要更加清醒和理智的想問題。Agile 是一種實踐的方法論，需要大量實踐和經驗才能真正的去理解它，另外一方面，從傳統的開發方式轉型至 Agile，多多少少都會有過去殘留的痕跡，而這些看不見的痕跡，可能會暗暗的抹殺 Agile 最初承諾的效果。

Agile 是一種好東西，某種意義上，資本家從開發人員手里榨取了更大的價值，這是建立在效率提高基礎之上的，但它卻散發著無比的誘惑，或許大家希望自己少寫一些文檔，或許大家厭倦了瀑布模型的流程，或許。。。。

    這里我們要將 Tapestry 與其它主要的 Java Web 框架做一番比較，包括 Struts，JSF。

    Struts 是一個 Action 方式的 Web 框架，所有的請求直接對應了相應的 Action，我們需要通過一些相應的技巧性處理才能把我們在頁面上的 Click，Value Change 等轉換到后端對應的 Action，抽象程度顯得不夠高，并且這樣會使 Struts 在處理一些較為復雜的頁面時配置過多，造成開發和維護上的繁雜。另外 Struts 默認使用的 Tiles 模板框架使用了 <jsp:include> 方式的拼裝頁面技術，并且在每個頁面都需要配置，這樣的話，又增加了不少的配置量。在Struts中，經常需要使用標簽庫通過 EL（Expression Language）來顯示組件ActionForm中內容，這就涉及到一個結合的問題，標簽庫是別人寫的，而且 Struts 在這方面并沒有確定的標準，如何才能讓自己的組件庫和現有的組件庫很好的結合，難度和麻煩就體現在這個結合點上。

    JSF的視圖層開發的基本思路和Struts差不多，只不過換了不同標簽庫，也需要標簽庫+組件的結合思考，不過因為組件這里是通用組件，沒有什么限制，并且遵循了一個共同的標準，所以這樣比Struts要輕松一些。JSF 提供了一套完整的生命周期和組件標準，我們很容易的為其定制一些組件和使用現有的組件庫。另外JSF采用了事件驅動的方式，同一個頁面對應的多個 Action 請求會比較直接的通過 EL映射到后端對應的 Java 方法上，從而大大減少了復雜頁面的配置量。但是在默認情況下，JSF 每個頁面的都需要配置其單獨的導航，如果頁面導航復雜的話，配置還是不少的。JSF 在默認情況下并沒有集成模板引擎，但是開源的 Facelets 模板引擎提供了類似 Tapestry 的模板方式，從另外一種方式簡化了 JSF 的開發。JSF 采用了 HTML 頁面保存組件樹的機制，頁面的所有組件和組件狀態被序列化到頁面中或者 Session 中，這樣的話，如果在頁面上 Javascrīpt 通過修改 DOM 的方式修改頁面的組件，會導致頁面和組件樹不一致，導致 JSF 無法正常工作，但是可以通過 Ajax 方式向服務端發出更新組件樹的請求，但這樣需要走完 JSF 整個生命周期，顯得較為笨重，所以從架構上來看，JSF 在處理頁面問題上不夠靈活，也不夠 Ajax 化。

    Tapestry使用了組件庫的概念替代了標簽庫，沒有標簽庫概念，這樣就沒有標簽庫和自己的組件需要結合的問題，都是組件的使用，組件中分Tapestry標準組件和自己定義的組件，這也是接觸了JSP體系的人學習Tapestry面臨的一個思路轉換。這樣極大的減小了頁面修改而帶來的修改難度。同為事件驅動的框架，在配置上 Tapestry 有著和 JSF 類似的優勢，我們只需要簡單的在 XML 文件里配置事件和后端方法的對應關系，或者使用 OGNL 直接在頁面中與后端方法建立關聯。在頁面導航上，Tapestry 是根據監聽器方法的返回值而確定，這樣就省去了頁面導航部分的配置。Tapestry 的模板技術天生就是其優勢所在，這樣的方式將前臺頁面的制作和后臺業務系統的開發完美的結合在一起。Tapestry 因為沒有 JSF 這樣的組件樹綁定的方式，就能夠比較容易的和 Ajax 綁定在一起，目前開源的 Tacos 組件庫就提供了很多這樣的組件，并且整合了 Dojo Toolkit 使得我們開發頁面中有了更多好用的組件，并且只需要很簡單的配置工作就可以使用功能強大的 Web 組件和 Ajax 功能。

    另外，JSF/Tapestry不只是支持HTML，也支持多種客戶端語言如WML或XUI等。

    雖然看起來兩者似乎沒有什么聯系，但是看起來 工作流 的一些概念和狀態圖有著驚人的相似之處，或許是我過去對 UML 的理解太少了，而對 UML 的理解有僅限于 Class Diagram 和 Sequence Diagram，而且僅僅是一些粗淺的認識，而在和 Sze Hung 老大以及 james 討論問題的時候，也經常遇到狀態機的概念，或許是我在這方面太過于薄弱了。今天在 dearbook 定的 UML User Guide 2nd 也到了，這本凝聚了 Rational 三巨頭的心血之作中貫徹著這樣的思想。希望能夠從中吸取更多精華吧。

    很多粗人都常常認為 UML 只是畫圖的東西，三兩頁就可以講完的東西，何必弄這么多呢，還印出 n 多本書，簡直就是騙錢了。其實說來，UML 難道僅僅是一種圖形工具嗎，它凝聚了更多更深刻的 OOP 的概念，在各種各樣的應用中才發現，原來 UML 比我開始想想的要豐富的多。

    看過一些人在網上的評論，才發現，其實人民郵電出版社和機械工業出版社的書其實并不是太差了，只是機械的紙實在是說不過去，在我書架上放的一堆書中，原來清華大學出版社的書是最差的，無論從紙張，從排版，從翻譯，因為有康博這樣被罵死也還要出來招搖撞騙的所謂翻譯團隊。近些年來，一些出版社都開始建立了一些自己的圖書品牌，比如說電子工業出版社的“博文視點”，比如人民郵電出版社的“圖靈系列”，我個人感覺其中的書的選題和印刷都還不錯，雖然也會有一些比較爛的作品出來了。

　　今天看了一篇很有意思的文章， http://m.tkk7.com/uiiang/archive/2006/10/30/77993.html ，介紹了種種項目中的編碼的惡習，其中很多的東西看起來真的是很搞笑，比如趴在Tab上睡著了那個，用中文做變量名的，還有 if(condition) a  else a 那個也比較搞笑，算是夸張了點。

　　不過想想看，自己一直都在算是比較正規的軟件企業，編碼規范還是有一定的要求的，不會出現這么搞笑的問題，不過有些問題還是會經常的犯，比如說，又一次看一個同事寫一個方法寫了 1500 行，我立刻讓他改，最后精簡代碼，分開寫，也算是減少到可以接受的程度，另外一個惡習就是復制代碼，很多開發人員自身都是不怎么會寫代碼的，做開發就是找過去相識的，復制，粘貼，改，所以會出現一堆比較搞笑的問題，于是，錯誤便不是自己犯的了，人家寫錯了，自己也就抄錯了，我在第一次參加 Code Review 的時候就碰到這個情況，我自己的東西都是自己手工寫的，出現了一些問題，被大家指出來了，其它人寫的東西都是抄來抄去，發現問題都不是自己的，因為改過去的代碼需要上面授權，還有一堆測試要重做，所以看大致是可以用的也就蒙混過關了，造成了越來越混亂的代碼。

　　其實說來要把代碼寫的更好一點沒有想象中那么難的，凡事從小做起，從點滴做起，慢慢的把一些好的東西變成自己的習慣，重要的是要積累，而不是放任自流，多去看看人家著名的開源項目，看看人家代碼是怎么寫的，多去和自己的比較，然后善于用一些 Audit 工具評估自己的代碼，讓自己對自己的代碼中出現的問題有一個更明確的認識，然后慢慢的去改變自己的習慣，其實從長遠角度來說對自己有很大的好處的，起碼自己的編碼能力提升了，基礎更加穩固了，有能力去勝任更高級的工作，不然，天天復制別人的代碼，自己又天天只能寫出來一些不符合規范的代碼，而自己又天天不去想不去問，一直這樣下去，開發能力還能提高嗎？

　　其實我還是很喜歡一本書《代碼大全 2nd》，今年上半年才出來的中文版，里面針對我們開發的時候出現的問題給出了很多規范和解決方案，我會經常抽空去看看這本書，然后想想自己該如何去改善自己的開發習慣，去寫出更好的代碼，另外就是用一些 Audit 工具去針對自己的代碼做出一些評審，比如 CodePro，另外我們一些同事在 Maven 上用一些插件對 CVS 上的代碼做出 Audit 并發布在項目站點上，這些都是不錯的手段了。

　　其實說來最重要的還是自己的態度，工具，好的方法都不能轉變對于開發惡劣的態度的。

     摘要:   閱讀全文      摘要: 這幾天突發奇想，過去通過一些對 Navigation 的實現來省去了 JSF Navigation 的配置，現在又有新的想法了，能不能在 face-config.xml 中連 Managed Bean 都不要配置了呢，答案是肯定的，并且在實踐中也得到了證明。  閱讀全文     花了近一周的時間，把 iCustomer 大改了一番，其實說來也沒有特別大的變化了，修改的東西只不過是一些過去的一些bug和網上朋友們的一些建議，其實重點還是放在改 bug 上，另外就是 Order 這部分系統的領域模型重構，Order 與 OrderItem 之間的關聯由原來的 one-to-many 改成了現在的 composite-element 方式，參考了 Hibernate Reference 的內容，從理解上來說這樣的關聯方式也是比較合適的，有過去的松散的關聯方式換成了現在這樣緊密的關聯方式。通過前面近兩個月對 Hibernate 概念更深層次的思考與理解，現在在處理起這樣的問題都變得輕松了很多，沒有那么多的問題會很讓我在開發中卡殼，而且是那種一卡就卡上個好幾天不能解決的。當這樣的關聯關系復雜了以后，Hibernate 的功效才更好的發揮出來了，我們拿關聯對象就不用再寫一堆方法去拿了，需要的時候去取，Hibernate 就會自動的取幫你取好。實際上這次改 Order 部分時候，很多情況下都是在刪過去的代碼，過去的方式真的太復雜了，全部要自己手工一個個的去拿，簡直就是把 Hibenate 當 SQL 用，從思想上來說，這顯然是不正確的。

    另外想想看，如果在一個項目中用起 Hibernate 或者使用同樣方式的 EJB3 Persistence 真的會存在著太多的風險了。Hibernate 走的是方式上的變革，我們必須去用新的思想去考慮問題，而不是僅僅用用它而已，我們需要從對象建模的角度就開始考慮 ORM 的存在，以對象為中心的方式去組織業務邏輯，而不是以表為中心去組織，剛開始用 Hibernate 的時候，大部分情況還是在考慮表如何如何的，但是用了一段時間以后，發現這樣的方式和 Hibernate 真正的核心思想相差太大了。所以說要正確的去用 Hibernate 決不是看了一兩本書，做了幾個簡單的 CRUD 就可以的了，需要在許多復雜關聯中經受考驗才可以，而一個要很好的去用 Hibernate 的項目，一定是要有這樣經驗的人去做才可以的，幾個剛翻幾頁書，知道怎么用就去拿 Hibernate 做項目的人真的還是遠遠不夠的，這種情況在 iCustomer 0.1 版本中表現的非常突出，混亂的配置和關聯關系，讓使用了 Hibernate 后，代碼未減反增，我努力在 0.2 的版本中做出一些修改了，當然只是比原來好了一些，離真正理想的情況還是有差距的。當然有空我會把這樣的一些經驗和大家分享一下，讓大家在學習 Hibernate 上少走一些我曾經走過的彎路了。

    又用回了 JSF，開始發現這樣的方式真的有很多的好處了，而且在 JSF 的使用和經驗上有一些積累，用它來建立一個不大的項目經驗應該是足夠的了。Backing Bean 的方式比 Action 的方式配置文件的數量上要減少了很多，說能夠減少到原來的 1/4 甚至更多都不為過了，因為我們一般情況下一個 Backing Bean 對應一個頁面，只需要配置一處，而一個頁面中如果有很多操作的話 Action 方式就需要配置很多了，比如一個查詢頁面，查詢需要一個 Action，查看查詢的一個記錄需要一個 Action，刪除記錄需要一個 Action，修改一條記錄又需要一個 Action，算起來正好 1:4，是不是省了很多配置呢，在結合擴展的 Navigation 方式，連 Navigation 都不需要配置了。配置文件真的少了很多了。

    用到了一個 Tomahawk 組件中獨有的 forceId 屬性，不能說有多爽，但是可以讓你在寫 JavaScript 的時候省了好一些代碼了，過去一個組件的 id 生成出來就是 form:cid 的形式，而用了 forcdId = "true" 后，生成出來的 id 就是你在組件的 Tag 中實際定義的值，當然用的時候也要小心了，千萬不能重復，包括同一頁面中不能重復，也包括一個頁面中包含另外一個頁面時不能重復 。

    連續三天做了三場 Share Session，講了一些關于系統開發的三個層的東西，Web Layer / Business Layer / Persistence Layer 分別以各個層面最優秀的技術為例和組內組外的同事們分享了一些我關于這些技術的理解。

    雖然說講的還不是很好了，但是這三天卻給了我很大的提高，不僅僅是技術上面，更多的是在一種表達能力方面的。可以說是第一次真正意義上的上臺講東西了，因為面對的不光是同組熟悉的同事，還有很多不是太熟悉的，還有幾位老大，甚至在最后一次講JSF的時候，大老板還進來坐了一會，壓力還是挺大的，雖然要講的東西已經在之前在腦子里演練無數次了，但是要想把自己想的東西和別人講清楚，的確不是那么容易的事情了，當發現下面的同事滿臉的迷茫，就得趕緊換一個角度來說明問題，不過還算過得去的是，自己并沒有太多的緊張了，雖然是第一次正式的在臺上講東西，面對面的對著大家，不過自己要講的東西心里還比較有底，心里比較踏實了，于是也就沒有太多的緊張了。

    通過三天對各個方面的技術的介紹和總結，其實也不知道大家真正能理解多少，因為太多東西沒有經過實踐是不會有太深刻的理解的，雖然有些東西當時是聽懂了，但是卻不會深深的刻進你的腦子，時間一長就忘記了。三天里，總結了這一年來我對 Java Web 開發的幾個方面的理解了，雖然這一年學到了很多很多，但還有太多太多的不了解了，有些東西當自己看的時候覺得自己了解，但是當需要把這個東西和別人分享的時候，卻發現自己有太多太多的不知道了。

    似乎很久沒有寫些什么了，因為最近想的太多，做的太少了。
    第一次發現 Hibernate 原來并不是自己過去想像的那樣簡單，它很復雜，很強大，卻能讓你最后要做的事情變的很少，雖然它帶來了如此多的好處，但如果想真正的用好它，必須有一個非常熟悉它的人在你的團隊里，這樣才能夠最大的發揮它的巨大威力。雖然每個人都可以花不多的時間去用會 Hibernate ，但卻只有很少的人能夠靈活的駕馭它，讓它為你服務，因為它同傳統的關系數據庫可以說是截然不同的兩條路，從玩 SQL 走過來的人，多多少少會受到它的限制，而變得不易接受ORM，像我就是一個典型了，當得到高手指點的時候，發現過去的很多想法偏離軌道還是挺遠的了，幸虧有人指點，得以走回正道。
    作為 J2EE 中另一個驕傲，Spring 也以它的獨特觀點改變了 J2EE 的世界，過去用 Spring 只是稍微理解了它的 IoC 的思想，和簡單的使用了它的 Transaction 管理功能，最近細看了一下它的 AOP 感覺震動還是挺大的。基于 Interceptor 的 AOP 真的是很好用，也很強大，甚至于說，它會是一種改變 Java 開發模式的一種動力了，雖然只是剛開始看看，沒有什么深刻的理解，但卻也能夠有一些很大的感觸了，或許 AOP 在目前還是剛剛起步，或許太多的人沒有接受它理解它，AOP 的應用層面還是比較低了。

用 Hibernate 碰到一個很傻的問題，在 iCustomer 中有這樣的關聯，有服務記錄，該記錄會與 Customer 關聯，當時為了在不需要的時候不在 VO 里 new 出 Customer，用了這樣的寫法。

public Customer getCustomer() {
?if (null == customer) {
??customer = new Customer();
?}
?return customer;
}

這樣看似沒有問題，當使用到 Customer 的時候才會創建該對象。但是每次卻會報告臟數據錯誤，其實最重要的是我忽略了一個問題，這個方法同樣會被 Hibernate 調用，在 null 的時候給 new 出一個相應的 Customer，這樣就會出現問題了，如果你把 Customer 設成 null，Hibernate 調用該方法時就會自動給你 new 一個 Customer，并沒有任何 id，這樣在保存的時候會引發臟數據錯誤。所以一定要避免這樣的寫法。

別人給出的建議是把這樣的 new Customer 的邏輯放在外面寫，手動處理 Customer 的創建。頁面上傳遞的是 Customer 的 id，后臺手動加載 Customer 的 PO，然后 set 給 Support。

　　經過大約四個月的開發，和五位開發設計及美工人員的努力，AgileJava iCustomer 的第一個不是那么穩定的版本終于拿出來了，我們終于走出了我們的第一步，在這期間，我們也得到了很多朋友的支持和幫助，我們要感謝這些支持者的貢獻。

　　在這個階段里，我們團隊成員一起把我們研究 JSF, Spring, Hibernate，以及 Acegi 的成果都集中在這個項目中了。雖然很多東西都只是那么點點滴滴，但是在這期間有很多朋友在積極的幫助我們，參與我們的 OpenDoc 活動，把自己的寶貴時間分享出來，為大家帶來了很多很好的文檔，上周末，我們得到了 javascud 的大力支持，我們有了自己的 SVN，有了自己的 JIRA，這樣的話，我們便可以建立我們自己的協作開發平臺，讓我們的經驗和更多的朋友分享，同時，我們也歡迎更多的朋友能夠參與到我們的開源活動中來，因為有了你們，我們才可以更壯大，因為有了你們，我們才可以更成熟，因為有了大家的齊心協力，我們才能為了一個共同的目標去奮斗，因為有了大家的協作，我們才會在共同努力中進步。

　　開源也不是一句口號，我們只想用我們自己的行動來證明這一切，正因為我們是熱愛開源的，所以我們才會去努力做的更好；正因為我們有著一個奮斗目標，我們才會孜孜不倦的去奮斗。此前 SpringSide 為我們做出了一個榜樣，EasyJF 讓我們夢想在自己的努力中實現，CowNew 也成為我們開源一個很好的先例，正是因為大家有這個夢想，有這些前輩們的努力，我們才看到國內開源的希望。

　　其實我們更希望做到的，只是讓新的技術能夠更貼近實踐了，讓大家的實踐能夠更容易，讓大家的開發能夠更輕松，所以我們才從過去只是為了朋友做的一個小小的系統中找到方向，所以我們的開源團隊名稱叫做 AgileJava 就是為了讓我們的開發更敏捷。

　　下面我簡單的介紹一下我們現在已有的系統和我們未來的目標：

　　AgileJava iCustomer 系統是一套開源的 CRM (客戶關系管理) 系統，使用了新一代輕量級 J2EE 技術： JSF，Spring，Hibernate， Acegi 等作為系統的基礎開發框架，力圖打造一個輕快好用的 J2EE 應用。

　　在系統開發過程中，我們同時將系統中的基礎框架以及大量可以簡化 J2EE 應用開發的組件從應用中抽取出來，并獨立提供給廣大開發人員，作為項目開發的基礎框架，為大家進行快速開發提供支持。我們為該框架命名為 AgileJava Framework。 AgileJava Framework 的目標是致力于為廣大開發者提供一個敏捷高效的 J2EE 快速平臺。

　　另一方面，我們將以此框架為基礎，通過 Eclipse Plugin 的方式提供一套完整的基于代碼生成的解決方案，用于快速生成應用的基礎代碼。該開發工具同樣沿用我們 AgileJava 的名稱，叫做 AgileJava Studio。 AgileJava Studio 將致力于減少開發工作中的重復勞動，給開發者帶開更好的開發體驗。

　　我們將會將 AgileJava iCustomer， AgileJava Framework， AgileJava Studio 作為開源項目來運作，一方面建立一個完整的企業級的客戶關系管理系統，另一方面建立一個為 J2EE 項目提供快速開發能力的基礎框架和開發工具。

　　因為國內的開源模式一直沒有什么好的先例，并且開源的路線在國內因為一些誤解方面的問題，一直沒有很好的發展起來，雖然我們選擇了開源，但是我們更多的希望只是通過一個完整的企業級應用的方式來探索開源的方向，并為我們中小型企業級應用打造一個方便易用功能強大的解決方案，用我們的實踐帶給所有參與者一些經驗，無論是開源方面的經驗，還是在輕量級 J2EE 應用開發的經驗。雖然國內很多軟件企業都在用這些技術，但因為版權的問題，無法和更多的朋友分享，所以我們更需要一個開放的交流環境，通過這樣開源的方式，通過大家的努力，把我們在實踐中的經驗拿出來，和大家分享，共同促進我們軟件開發的大環境的改善，共同提高大家的開發能力和開發水平。

　　在這里，我們鼓勵的是一種知識共享，通過這樣的共享，我們把我們自己擁有的一份知識擴展到大家擁有的無數份知識。我們通過自己的實踐，我們能夠更深入的去了解了現有的各種技術的長與短，通過大家的交流與協作，我們在知識上互相彌補。通過這樣的實踐，我們不光是再做我們這個系統，更多的是我們有了更多的思想，更多的經驗，我們有能力去打造更好的系統。

　　我們目前采用了以 JSF, Spring, Hibernate 為中心的主體框架，并努力使之擴展到一個中小型商業應用所需要的主要技術領域，并使之更簡單易用。

				 目前采用的技術：
 JSF (Myfaces Implement)，完整的視圖層解決方案，一個標準的事件驅動的 MVC Framework。
 Spring Framework ： 其 IoC 容器為我們的業務對象控制帶來了很大的便利。
 Hibernate 3 ： 目前最優秀，使用面最廣的 ORM Framework。
 Acegi ： 一個基于 Spring 的通用 Security Framework。
 Quartz ： Java 世界最好也幾乎是唯一的 Job Schedule 工具，為我們調度 Batch Job 提供了很大的便利。
 Shale ： struts 社區在 JSF 領域的重大貢獻，以 JSF 為基礎為我們提供了一系列好用的東西。

		

				 預計后面準備采用的技術：
 Compass + Lucene ： Java 世界里最好用的開源 Search Engine 組合，Compass 使 POJO 能夠更方便的去使用 Lucene 的底層引擎。
 BIRT ： Eclipse 社區貢獻的一個重量級 BI 應用。當第一眼看到它時，就拋棄過去的 iReport + JasperReport 的組合了,夠專業。
 Facelets ： 為 JSF 量身定做的模板框架，JSF 的 Fans 們不用再靠著 struts 的 tiles 也能活啦。
 AjaxAnywhere ： 不用寫 JavaScript 也能 Ajax ，它為我們提供了這樣的可能。
 ICE Faces Component?: 當它的第一個beta版本出來的時候，我就對它頗有興趣，或許是目前免費的 JSF 組件庫中最好的 Ajax 實現了。

		

　　我希望能夠有更多熱愛開源的朋友加入到我們的行列中來，不論你來自何方，做著什么樣的工作，只要我們有著開源的這個共同的目標，我們就可以共同的去為著自己的愛好，自己的理想，自己的信念所奮斗，記住，開源決不是三分鐘的熱度，需要你持之以恒的奮斗。

     摘要: 過去的一段時間，一直有人拿 JSF 的 Navigation 當靶子，批評 JSF，其實細心的人會發現，在 Java 世界，這樣的批評常常是很片面的，幾乎所有成熟的應用框架，在除了實現某些默認的功能外，還保留一些擴展的接口，提供了相當的擴展性，比如說 struts， spring 等很多的 web framework 都提供了很多擴展的接口，當然，JSF 也一樣。JSF 的 Navigation 中，我們一個 page 都有一個 from-view-id ，它的每個 navigation 出口 to-view-id 都必須定義，所以在不同的 from-view-id 中會有一些重復的 to-view-id，并且每當有一個新的 navigation 路徑，我們都必須配置這個路徑，才能夠在 action 中正確的轉向我們這個路徑。很多情況下，這樣的方式用起來都不是很爽，我們需要有一些簡單的方式，我們在 action 事件中，直接 return 一個 page 的 path 就會直接 forward 到這個 page ，在用的時候會方便一些，有沒有辦法去做到呢？  閱讀全文