JBoss釋出了支援Groovy並增強了JSF的Seam 2.0

今天JBoss Seam團隊釋出了Seam 2.0。這個版本與上個主版本的釋出相隔8個月。專案成員Norman Richard列舉了這一版本的主要特性：

• WebServices——Web service可以是會話式的，而且可以利用Seam的元件和服務。
• Groovy——可以用Groovy寫Seam元件
• 熱部署——在開發模式下，Seam可以熱部署元件定義而無需重新部署整個WAR或者EAR。
• 支援Eclipse——在JBossTools中對Seam 2的支援包括專案嚮導，整合測試，JBoss EL自動完成，檢視頁面的視覺化編輯等等功能。
• 不依賴於JSF——Seam已經與JSF解耦，現在它可以更方便的與其他web框架整合。實驗性的與GWT整合的原型已經完成了，我們可以看到Seam如何與GWT協同工作。
• 支援JSF 1.2——Seam已經把它的預設JSF實現從myfaces切換到JSF RI。
  
• JBoss EL ——Seam提供了對JBoss EL的支援，支援引數化繫結、非JavaBean屬性與投影。
• Maven——Seam自己的依賴關係由Maven管理。有一個Maven repository是可用的。
• 整合——Seam可以與許多流行的專案整合，例如Quartz，JFreeChart，Hibernate Search和iText

InfoQ與Seam的專案領導人Gavin King討論了Seam新的版本。InfoQ的第一個問題是相對與Seam 2.0版，1.0中最大的不足是什麼：

我認為在1.0中我犯的最大的錯誤是：

（1）開發Seam的時候假設使用環境為JSF，EJB3和JTA。這些技術毫無疑問都是非常流行的，但是仍然有很多人要求在其他環境中使用Seam，他們推動我們開放了Seam的實現，現在Seam可以支援其他環境。

（2）沒有認識到我們內建的元件庫會增長的如此龐大。在早期的版本中，我天真的把所有內建的元件放在org.jboss.seam.core包中。在Seam 2中我們不得不徹底重新組織了包結構。

接下來King比較了JSF元件技術與把整個表現層放在瀏覽器中的技術，例如ExtJS：

我認為我們主要需要考慮兩點：

（1）你喜歡用宣告式的方式還是程式設計式的來定義使用者介面？

（2）在客戶端到底有多少功能可以被真正執行？

還有一個問題，你希望的型別安全是什麼樣的。

所有這些問題幾乎都是正交的。例如，GWT提供型別安全的，程式設計式的，客戶端的方案。另一方面，Wicket提供型別安全的，程式設計式的，伺服器端的方案。

JSF在某種程度上是型別安全的，宣告式的，伺服器端的方案，如果需要的話，你也可以選擇程式設計式的方式。每種方式都有它自己的優缺點，但是我認為JSF的方法是強迫性的：

首先，我必須用一種宣告式的語言來定義使用者介面。使用者介面本質上是分層的，而我希望我的程式碼結構能夠反映這種本質。我對於使用swing風格的 程式碼來建立使用者介面總是覺得彆扭。這種程式碼看起來總是很醜陋而且難以維護——有點象通過遍歷DOM樹來解析XML的Java程式碼。這裡存在基本的結構性的 斷層。

對於使用者介面中動態性強的部分，程式設計式的操作當然更有效。但是，動態性強的部分是很少的。除了個人控制級別的介面以外，大多數使用者介面是靜態的。而JSF 在處理動態性的介面時也是很強大的，它允許你在Java程式碼中直接操縱JSF元件。當然，你可以選擇使用JavaScript程式碼來操作瀏覽器中的DOM 物件。（總有一天，有人會建立一個JSF實現，使得客戶端可以訪問JSF元件樹，但是我們現在沒有實現這個功能。）

其次，我不認為把更多的狀態和應用邏輯放在客戶端執行會減少很多開發工作。有太多事情只能在伺服器端有效的處理：持久化，安全，資料級別的併發，等等。如 果你把試圖把你的應用程式碼放到客戶端，那麼你最終會回到我們3、4年前的狀態，會有這樣一種架構，其特點是：有一個無狀態的服務層，一些資料傳輸物件，細 粒度的手工方式的獲取資料以及合併資料變化。這是痛苦的程式設計模式，我們採用有狀態的元件和會話範圍的持久化上下文——這兩種都是伺服器端技術——剛剛從其中逃脫。

使用RichFaces和Seam，你可以建立這樣的使用者介面：非同步的獲取資料，互動式的更新檢視，非同步的響應使用者互動，互動式的應用變化，這些動作都處 於一個良好定義的樂觀事務中，沒有任何煩人的重複工作。當然，學習JSF和RichRaces比使用其他方式要多花一些時間，但是從長期來看這些代價是物 有所值的。

我所認為的JSF方式的最大的弊端目前很少被提及：使用EL把檢視繫結到模型時缺乏型別安全。我理想的環境應該支援一種真正型別安全的宣告式語言來定義使用者介面。可惜，Java不能真正支援建立這樣的DSL。遺憾。

InfoQ然後詢問了關於新的Web Beans JSR的話題：

Web Beans有許多思想是從Seam得來的：

• 上下文相關的元件
• 會話
• 按照優先順序規則的元件覆蓋
• 與Java EE的深度整合
• 基於註釋繫結的攔截器繫結
• 事件通知

與此同時，Web Beans還從Guice"剽竊"了基於註釋繫結的依賴注射思想，這導致了影響深遠的後果。

Web Bean集這些思想之大成而形成了一個非常獨特的程式設計模型，該模型強調“鬆耦合與強型別”。你可以利用Web Bean的優勢完成一個非常鬆耦合的應用：

• 使用上下文相關的生命週期管理（有狀態的元件象service一樣相互互動）來解耦客戶端和伺服器端的生命週期
• 使用部署時元件覆蓋來解耦客戶端與伺服器端的實現
• 使用事件通知來解耦訊息生產者與消費者
• 使用攔截器來解耦橫切（技術上的）關注點

所有這些功能都沒有犧牲型別安全。所有的工作都是通過型別安全的註釋完成的——沒有隱藏起來的字串，準備在執行時突然咬你一口:-)總的來說，Web Beans建立在Seam的傳統之上，但是我相信它是一個更加強制性的模型。我有一個出色的專家組保佑著:-)

最後，我們問起King在使用Seam開發新的執行在in.relation.to上的wiki時，團隊是否發現了Seam框架的一些漏洞：

我們發現了一些bug和小的限制。但是開發Wiki帶來的最大影響是激勵我們為Seam開發一個外掛架構。這裡我們所指的外掛，是類似於portlet那樣的東西，只是不那麼弱智。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13270562/viewspace-244085/，如需轉載，請註明出處，否則將追究法律責任。