看到這篇文章， 是一群Java 框架的設計師們談框架的優(yōu)劣， 有趣的是，大家眾口一辭對Rails持不同程度的褒揚。

Jave Web Framework Sweet Spots

 

Jave Web Framework Sweet Spots
Java Web 框架的“甜點(diǎn)”

這是一篇很有趣的文檔，所以摘要一下，其實(shí)類(lèi)似閱讀筆記，好像是3/25發(fā)布的：

不知怎么翻譯Sweet Spots，難道翻譯為甜處、甜頭、蜜點(diǎn)、蜜穴？

這時(shí)基于對以下人的采訪(fǎng)：
JSF  Jacob Hookom
RIFE  Geert Bevin
Seam  Gavin King
Spring MVC Rob Harrop
Spring Web Flow Rob Harrop and Keith Donald
Stripes  Tim Fennell
Struts Action 1 Don Brown
Tapestry Howard Lewis Ship
Trails  Chris Nelson
WebWork  Patrick Lightbody
Wicket  Eelco Hillenius

原文在此：http://www.virtuas.com/articles/webframework-sweetspots.html

JSF(Jacob Hookom)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
當你希望瀏覽器程序像桌面程序一樣工作的時(shí)候，你可以遵循標準并獲得大量第三方支持。它致力于降低復雜度。它允許你不與view和特定的action、參數傳遞、狀態(tài)傳遞、渲染打交道就可以進(jìn)行高質(zhì)量的開(kāi)發(fā)，不管是否使用工具。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
它不適合大規模的、只讀（其實(shí)指讀為主）的網(wǎng)站。在這種情況推薦Struts，因為知識庫豐富（應該指文檔和用戶(hù)群）。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
Seam：
優(yōu)點(diǎn)：非常簡(jiǎn)單直接
缺點(diǎn)：對于大項目過(guò)于簡(jiǎn)單；沒(méi)有模塊化開(kāi)發(fā)的好例子
Struts：
優(yōu)點(diǎn)：巨大的文檔和用戶(hù)群；跟著(zhù)它沒(méi)錯
缺點(diǎn)：狀態(tài)/行為的分離過(guò)于教條化
WebWork：
優(yōu)點(diǎn)：比Struts易于使用
缺點(diǎn)：復雜的UI難于維護，UI代碼過(guò)于復雜（JSF作者對action Framework都攻擊這一點(diǎn)）
Tapestry：
優(yōu)點(diǎn)：概念新穎；可以應付復雜的UI
缺點(diǎn)：對于一個(gè)組件化（JSF主要競爭對手），它依然依附于page/action的概念
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
他認為JSF這個(gè)標準下這些應該有第三方提供。JSF(2.0)會(huì )提供“Partial Faces Request”，它是Ajax實(shí)現。JSF也會(huì )增強annotation組建編程。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
很多JSF書(shū)都拿Struts作為對比。他認為這不能體現JSF的特點(diǎn)。他認為Struts和WebWork能做到的JSF也能做到。
6、你對Ruby on Rails的看法如何？
它與WebWork一樣好用，它的CoC（Convention over Configration）和腳手架非常好用。他認為CoC可以被應用在任何framework，他認為這是RoR最大的優(yōu)點(diǎn)。他還認為RoR會(huì )走上其它 framework的路（復雜性等），因為人們需要自己的擴展。

RIFE(Geert Bevin)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
你可以付出10%的工作量，得到其它framework的90%的……，它是一個(gè)full-stack framework（如RoR）。它吸收了成熟的分層框架的架構，并將共同的優(yōu)點(diǎn)匯集在一起。提供了web continuation，POJO驅動(dòng)的CRUD生成，可擴展的基于組建的架構，無(wú)session的狀態(tài)控制，關(guān)注REST作為API，雙向無(wú)邏輯模版引擎，集成了內容控制框架（CMS？）。每個(gè)層次的組建提供了可復用性（AOP，site，sub-site，page，widget，portlet 等）。適合于團隊快速開(kāi)發(fā)公共Web項目，適合喜歡開(kāi)發(fā)可復用組件的人。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
團隊中的每個(gè)人都有其它framework的知識，難于培訓他們。開(kāi)發(fā)狀態(tài)相關(guān)的服務(wù)器端Web組件，而不是用RIA或Ajax去實(shí)現。第三方支持很重要的情況下（可憐RIFE用戶(hù)群還不大）。他推薦這種情況下使用JSF?；蛘咴赬ML為主要發(fā)布形式的情況下，推薦Cocoon。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
他試驗過(guò)WebWork，JSF，Wicket。他喜歡WebWork的簡(jiǎn)單，但是不喜歡它的模版方式（tag的template，應該），它也不提供組件封裝。他認為JSF的工具支持非常吸引人。Wicket的純Java實(shí)現很不錯，可惜XML配置很不爽。
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
關(guān)于A(yíng)jax，RIFE剛剛集成了DWR，而且選定以后也使用這個(gè)。集成Dojo，Scriptaculous，Prototype都很容易集成進(jìn)來(lái)。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
這些錯誤理念：1、RIFE的XML配置繁瑣 2、RIFE是continuations server 3、RIFE重新造輪子沒(méi)有提供新鮮東西 4、RIFE的模版語(yǔ)法很蹩腳過(guò)于簡(jiǎn)單和業(yè)余 5、RIFE是基于request的framework 6、RIFE的功能太多，學(xué)習曲線(xiàn)陡峭
6、你對Ruby on Rails的看法如何？
RoR對Java社區的沖擊非常棒，元編成也得到了信任。RoR沒(méi)什么特殊之處，也沒(méi)有從Ruby語(yǔ)言獲益很多。
我討厭：它的模版。Partials（RoR中的組件）。URL的分散處理。Active Record提供了從數據庫schema而來(lái)的DSL，但是卻不是從domain model而來(lái)。沒(méi)有l10n和i18n支持。手動(dòng)狀態(tài)轉換。不能在JVM運行（……）。實(shí)際上腳手架生成了實(shí)際代碼。Ruby缺少工具和IDE。

Seam(Gavin King)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
擁有豐富用戶(hù)交互體驗的應用。方便實(shí)現多窗口的操作，回退的支持，單窗口多工作區，無(wú)狀態(tài)瀏覽。對商務(wù)流程（BPM）的集成是獨一無(wú)二的。Seam方便使用數據驅動(dòng)的ORM。遵循JSF和EJB3，多任務(wù)支持（多窗口/多工作區），BPM的領(lǐng)先解決方案。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
不適合只是將數據從數據庫顯示到網(wǎng)頁(yè)的應用，這時(shí)應該使用PHP或RoR。不適合需要設計特別的HTML組件的情況，此時(shí)應該選用Tapestry或Wicket。還在使用JDK1.4的人們。還有那些喜歡Struts的人（嘿嘿，夠狠）。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
JSF：喜歡他的事件/交互模型。喜歡他的EL和模型綁定。不喜歡那么多XML（為什么沒(méi)有annotation）。創(chuàng )建自己的controls太難了。
Tapestry：非常好。form驗證是它的殺手锏！模版方式很有創(chuàng )意。不過(guò)非基于POJO的組件模型則讓我對它失去興趣。
RIFE：這個(gè)東西很怪，但是有創(chuàng )業(yè)也有趣。我想進(jìn)一步學(xué)習。如果學(xué)習先要自費武功:D
Struts：這個(gè)東西的模型view綁定太復雜了。東西已經(jīng)過(guò)時(shí)了。
WebWork：比Struts好一點(diǎn)，不過(guò)也過(guò)時(shí)了。XWork曾經(jīng)是個(gè)很好的實(shí)現，不過(guò)現在也過(guò)時(shí)了。
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
Portal支持。遠程框架Seam Remoting Framework（Ajax）。模版消息的工具支持。以后還要集成ESB，計劃引擎和異步支持。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
這些都不是真的：JSF不能處理GET requests。JSF post后無(wú)法redirect。JSF不能與REST共存。
6、你對Ruby on Rails的看法如何？
它是PHP的很好替代品。如果它有一個(gè)正經(jīng)一點(diǎn)的持久化層它就可以和Java競爭了。

Spring MVC(Rob Harrop)和Spring Web Flow(Rob Harrop and Keith Donald)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
Spring MVC：
穩定可擴展，支持了i18n、文件上傳、異常處理，這些穩定的支持給開(kāi)發(fā)者堅實(shí)的工作基礎。是最佳實(shí)踐，告訴你怎么做是最好的。與Spring集成，領(lǐng)先的 IoC遠生支持。支持，Spring社區活躍和龐大。Struts開(kāi)發(fā)者可以平滑過(guò)渡。適合多種項目，可選的多種result類(lèi)型。
Spring Web Flow：
內置任務(wù)處理引擎，支持線(xiàn)性處理過(guò)程中的持續狀態(tài)。抽象，減少開(kāi)發(fā)的關(guān)注點(diǎn)。適合多種項目類(lèi)型，插件支持Spring MVC、Struts、JSF等。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
Spring MVC：不適合需要組件化開(kāi)發(fā)的場(chǎng)景。它是一個(gè)request驅動(dòng)的MVC。那些場(chǎng)景推薦JSF或Tapestry。
Spring Web Flow：處理線(xiàn)性頁(yè)面流，不適合一般的“自由瀏覽”。當然Spring Web Flow可以與request驅動(dòng)或者組件驅動(dòng)共存。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
Spring框架支持Struts和JSF集成。
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
Spring MVC：簡(jiǎn)化JSP標簽。更多的MVC配置schema。CoC風(fēng)格的默認控制器、URL影射、view，學(xué)習Rails和Stripes的優(yōu)點(diǎn)。增強數據綁定和驗證（支持范型綁定）。Portlet支持。Spring也要接受Ajax，使用DWR庫。
Spring Web Flow：一大堆，關(guān)心的可以自己看……
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
Spring MVC難于配置。在Spring 2.0，將會(huì )改善，可以使用自己定義的基于schema的配置。
6、你對Ruby on Rails的看法如何？
Spring MVC：RoR非常有趣。不過(guò)現在就拿出來(lái)用還有點(diǎn)幼稚。這里舉了個(gè)例子，關(guān)于變量的復數形式的處理，RoR會(huì )使用這樣的CoC風(fēng)格來(lái)處理變量list，而Spring MVC也實(shí)驗了種種風(fēng)格，但是受到的結果卻很差。人們認為英語(yǔ)的復數很古怪，沒(méi)有一定的規則，所以會(huì )帶來(lái)混亂，如（person -> people）。所以Spring MVC設計了變量+List的命名，personList更加明確，雖然這樣不酷，但更好用。就是說(shuō)Spring MVC要取其精華去其糟粕。

Stripes(Tim Fennell)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
與Spring MVC、WebWork等相同。它提供高質(zhì)量action驅動(dòng)的框架的同時(shí)，盡量簡(jiǎn)化配置，增進(jìn)開(kāi)發(fā)效率。Stripes適合復雜的數據交互的場(chǎng)合。這種情況下綁定驗證的強項就完全體現出來(lái)了，能夠很好的處理form和map轉換等。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
所有的action驅動(dòng)的framework都適合用戶(hù)在非Ajax驅動(dòng)的情況下在一個(gè)頁(yè)面進(jìn)行松關(guān)聯(lián)（loosely related）和無(wú)狀態(tài)交互的情況。適合每次都刷新的頁(yè)面。管理多窗口間持續狀態(tài)的應用會(huì )比較麻煩，此時(shí)應該選擇JSF。不過(guò)我認為90%以上的Web 程序都是前者，JSF只適合剩下的那9%，AJAX對于管理無(wú)狀態(tài)UI更加適合?？蛻?hù)端不需要AJAX，則可以看看Wicket，它更加簡(jiǎn)單。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
用過(guò)Struts、WebWork、Spring MVC。其中Struts做過(guò)商業(yè)項目，不過(guò)這個(gè)東西帶來(lái)的麻煩遠比帶來(lái)的效率提升要多。它認為這些MVC都有三個(gè)缺點(diǎn)：暴露了過(guò)多的復雜性給可發(fā)者。沒(méi)有提供足夠的開(kāi)發(fā)便利性，沒(méi)有提供足夠多的錯誤和提示信息，也沒(méi)有date格式化等小的便利（其實(shí)有）。穩當太差。
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
1.3要加入Inteceptor，實(shí)現AOP功能。驗證系統要加強。支持Ajax。我還在尋找一個(gè)好的Ajax/javascript庫。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
這些觀(guān)點(diǎn)：1、Stripes使用了annotation代替XML，只是換湯不換藥：由于元數據更接近代碼，所以修改默認的配置非常方便，不像XML那樣復雜，這是實(shí)質(zhì)的變化。2、Annotation意味著(zhù)你只能有一套配置：我認為90%的action都有自己的一套配置！Stripes會(huì )根據繼承關(guān)系尋找Annotations，子類(lèi)的annotation會(huì )覆蓋父類(lèi)的，因為像validation都是可以繼承的，如果特別需要還可以覆蓋。這樣很合理。在1.3中允許validations基于UI事件進(jìn)行。它向后兼容，不需要可以不用。
6、你對Ruby on Rails的看法如何？
我認為Java社區有很多可以從RoR學(xué)習的地方。Stripes學(xué)習了RoR的前端部分，開(kāi)發(fā)者可以減少配置量。但是RoR的RHTML讓我想到了以前的 JSP中混亂的scriptlet。而后面的ActiveRecord是一個(gè)很好的理念，實(shí)現的也很好。ActiveRecord比Hibernate等復雜的ORM工具要容易理解，因為這樣的特點(diǎn)RoR才引起了這么大的波瀾。

Struts Action 1(Don Brown)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
文檔和用戶(hù)基礎，書(shū)籍和背后的支持。容易雇到人（也容易找工作）。雖然其他項目的理念比這個(gè)要先進(jìn)，但是這些不算什么。實(shí)際上，Web層是很容易也很直接的。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
如果你需要portlets或者復雜的頁(yè)面（顯示很多東西），那么Struts要么無(wú)法工作要么太枯燥。這種情況你需要一個(gè)基于組件的framework，如JSF、Tapestry/Wicket。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
這些我基本都試驗過(guò)，他們每個(gè)都工作的很不錯。
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
Struts Action 2基于WebWork2，很快會(huì )開(kāi)始?，F在已經(jīng)支持Ajax了，我們在尋找更加容易的開(kāi)發(fā)方式，JSF支持（Struts Shale），continuation支持，還有支持更多的腳本語(yǔ)言（BSF擴展腳本撰寫(xiě)Action）。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
Struts太過(guò)時(shí)了，而且也不酷，難于使用。但是你可以自己修改或者擴展它。我認為團隊對于你的限制遠大于framework對你的限制。
6、你對Ruby on Rails的看法如何？
不需要D&D工具，旨在幫助開(kāi)發(fā)人員提高開(kāi)發(fā)效率的好例子。我們在A(yíng)ction 2中將學(xué)習它的先進(jìn)理念。

Tapestry(Howard Lewis Ship)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
我想Tapestry對于中等規?；蛘叽笠幠５膽脮?huì )帶來(lái)很多好處（甚至你可以在單頁(yè)面的應用程序中獲得好處）。這里有允許你創(chuàng )建新的組件的良好工具。 Tapestry不關(guān)心數據從哪里來(lái)，很多“項目類(lèi)型”都基于切面（aspect）（如CRUD vs. RSS feed vs. etc.）。我認為T(mén)apestry非常容易與IoC集成（HiveMind或與Spring），方便進(jìn)行測試。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
我在其它Java framework中沒(méi)有找到到強于Tapestry的優(yōu)點(diǎn)。但是對于RoR，我自己沒(méi)有使用過(guò)使用，很難說(shuō)RoR中的項目應該是什么樣子。我沒(méi)有仔細對比過(guò)RIFE，它看起來(lái)受了RoR影響，尤其是類(lèi)似ActiveRecord的數據訪(fǎng)問(wèn)層。但是如果你的應用需要特定的URL格式，那么在 Tapestry中奮戰勝算不大。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
在這兩年來(lái)我沒(méi)怎么嘗試過(guò)Tapestry以外的東西。我沒(méi)怎么學(xué)習RoR，因為時(shí)間太有限了。
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
Tapestry 4.0有很好的Ajax支持，通過(guò)Tacos庫。而Tapestry 4.1還要進(jìn)一步強化這方面的支持。
Tapestry 5.0提供了明顯的改進(jìn)：沒(méi)有abstract類(lèi)（Tapestry的怪癖:）。沒(méi)有強迫的繼承關(guān)系。對屬性進(jìn)行annotation而不是方法。沒(méi)有 XML，只有模版和annotaions。只能類(lèi)裝載，自動(dòng)尋找類(lèi)的變化。最小化API，超越annotaion。面向方面（Aspect- oriented）模塊構造，使用mix-ins。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
Tapestry 3.0還不容易測試，4.0改善了一些。Tapestry只是個(gè)人秀；實(shí)際上我們有很多活躍的貢獻者。Tapestry的學(xué)習曲線(xiàn)非場(chǎng)陡峭。它只有漂亮的模版實(shí)現；實(shí)際上Tapestry的特點(diǎn)在于狀態(tài)管理（允許對象存儲狀態(tài)，而不是多線(xiàn)程的單例來(lái)管理requests之間的游離和持久狀態(tài)）
6、你對Ruby on Rails的看法如何？
很有影響力。但是模版的實(shí)現非常丑陋。我聽(tīng)到了很多意見(jiàn)，關(guān)于RoR的優(yōu)缺點(diǎn)?；谖业幕纠斫?，這些觀(guān)念對Tapestry 4產(chǎn)生了影響（它對Tapestry 5影響更深）。
RoR 意味著(zhù)限制了你的選擇：如果你選擇RoR那么就要尊旬它的實(shí)踐（CoC..），看起來(lái)你的錢(qián)會(huì )花的恨值。這些類(lèi)似Microsoft的哲學(xué)。而Java更崇尚給你更寬松的選擇，不限定你使用的工具，但是曖昧的說(shuō)這需要你對你的工具理解更深。不僅對Tapestry，還對于JEE、Spring這寫(xiě) entire stack的框架，需要從RoR學(xué)習，不僅提供工具，還需要提供整套的解決方案。

Trails(Chris Nelson)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
Trails 的應用程序只需要Web界面和持久化的domain model就可以了。Trails給你的domain model快速的提供一個(gè)界面，除了POJO自己不需要附加的代碼。Trails允許你修改界面的外觀(guān)和行為，包括驗證、i18n、安全。這些都不需要 java代碼生成，不喜歡代碼生成的人應該感覺(jué)很舒適。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
Trails 講究夠用就好。它允許你快速交付，問(wèn)問(wèn)你的客戶(hù)：“這樣夠好么？”。這會(huì )改變你的工作流程，當然這不是可以覆蓋所有需求的解決方案。當UI需求很高， Trails沒(méi)有優(yōu)勢。我認為T(mén)rails適合于混合的應用，對于管理員他們只需要夠用就好，那么就可以使用Trails。其它的部分我們可以訂制開(kāi)發(fā)，我們在使用Tapestry、Hibernate、Spring來(lái)實(shí)現這些部分，Trails正是基于它們。對于非交互的應用，Trails也不適合，如報表應用，可以考慮Eclipse BIRT。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
我用Struts很多。它曾經(jīng)是偉大的framework。主要的缺陷是它不能自動(dòng)幫定數據到domain model。我也研究過(guò)JSF，它比Struts強，但是自定義組建非常難。Tapestry非常便于自定義組建，尤其對于建立高階組件（有其它組件組成的）非常方便，Trails正在使用它。
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
對于Trails來(lái)說(shuō)我們站在巨人的肩膀上。Tapestry在ajax功能作了很多努力，所以Trails也不難與其共舞。但是我們需要創(chuàng )建更多的例子來(lái)演示這些。我們也致力于讓Trails容易介入到已經(jīng)進(jìn)行的項目中。以后Trails還要加入基于實(shí)例的安全（instance-based security）（目前正在使用基于角色的role-based），還有method invocation。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
Trails是對RoR的移植。Trails的名字來(lái)自Rails。它是基于Rails的理念，但不是對它的移植。
6、你對Ruby on Rails的看法如何？
我認為我們有很多需要從RoR學(xué)習的地方，那將幫助我們享受開(kāi)發(fā)Web程序的愜意。

WebWork(Patrick Lightbody)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
一般來(lái)說(shuō)，WebWork一般適合小的團隊，它們愿意保持一雙臟手，學(xué)習開(kāi)元工具如何使用。WebWork不面向“輪椅程序員”，那些人只喜歡拖拽式的開(kāi)發(fā)。WebWork給花時(shí)間學(xué)習它的人回報。例如，直到輸入和輸出的人（閱讀了參考文檔，那樣很好）能夠容易的創(chuàng )建ActionMapper和 Configuration實(shí)現來(lái)提供“慣例”代替配置（CoC）的方便。我最近的例子中，URL是這樣 “/project/123/suite/456/test/create”影射到 “com.autoriginate.actions.project.suite.test.CreateAction”，然后自動(dòng)的傳遞參數： projectId=123、suiteId=456。而Result是“[action].jsp”或者“[action]-[result]. jsp”，也可以通過(guò)annotation來(lái)配置。
也就是說(shuō)，WebWork是你的應用程序framework中的最佳基礎工具。在這種情況以外也很好，但是目前不算最佳的“甜點(diǎn)”。
除去這些一般的，WebWork對于正在創(chuàng )建需要插件和擴展的產(chǎn)品的人是必備的。例如JIRA、Confluence、Jive Forums。因為WebWork支持廣泛的模版語(yǔ)言（Velociy和FreeMarker），完整的tag支持，模塊寫(xiě)好后非常容易插入。一個(gè)jar 包就可以包括所有的action和view（得益于ftl的classpath支持）。最終的效果很好：在Confluence中你可以通過(guò)管理界面上傳一個(gè)jar，這個(gè)plug-in就會(huì )自動(dòng)部署。這是因為Atlassian（Confluence、Jira的小組）非常了解這個(gè)framework，并且作了很多的貢獻。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
與其它action framework相同，WebWork在控制狀態(tài)和wizards上比較弱。如果你寫(xiě)了很多長(cháng)的wizards，JSF可能是比較好的解決方案。我還想說(shuō)，文檔還需要改善（參考文檔還不錯，但是教程、cookbooks和FAQ還比較差），如果沒(méi)有一個(gè)WebWork高手作為項目領(lǐng)隊，新手可能會(huì )敬而遠之。
對于非常簡(jiǎn)單的程序，我推薦使用簡(jiǎn)單的JSP或者Spring MVC，如果用戶(hù)接受Spring的話(huà)。但是總的來(lái)說(shuō)，我認為在action framework中WebWork是最好的。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
我試驗過(guò)RIFE、Spring MVC、Struts、Spring Web Flow，還有一點(diǎn)點(diǎn)Tapestry。我發(fā)現RIFE的概念很優(yōu)秀，但是它的實(shí)現不怎么樣。不難想象Geert還是使用“m_”作為字段的前綴。它看起來(lái)不像Java。模版難住了我，所以就沒(méi)有繼續看。
Spring MVC還可以，但是它是一個(gè)非常簡(jiǎn)單的framework實(shí)現。WebWork的數據綁定（WebWork世界中稱(chēng)為類(lèi)型轉換）要強多了，而且是自動(dòng)的（而Spring需要自己寫(xiě)property editors）。在Spring中的view替換支持泰有限了，而WebWork中的UI tags在Spring中壓根沒(méi)有提供。Spring中你可以使用JSP 2.0輕松的寫(xiě)自己的tag，但是不支持其它的語(yǔ)言。
Spring Web Flow：XML讓我抓狂。太過(guò)火了，不管Keith的主張，它“不支持任何的Web framework”。這個(gè)web framwork回避掉了WebWork、Spring MVC、Struts或者其它framework中的99%。我倒不是說(shuō)這是個(gè)壞主意，但是我應該誠實(shí)的說(shuō)它是一個(gè)完整的框架。
Tapestry 很優(yōu)雅，但是HTML屬性（jwcid）惹人厭。我接受這種理念，且實(shí)踐中這會(huì )帶來(lái)一些好處（Shale也有相似的地方）。但是實(shí)際上，我發(fā)現 “HTML/CSS開(kāi)發(fā)者”和“app開(kāi)發(fā)者”一般是同一個(gè)人，Tapestry就架設如此。實(shí)際上，由于A(yíng)jax的推動(dòng)，我想越來(lái)越多的“程序邏輯”會(huì )被嵌入到UI；這樣的話(huà)，Tapestry的模型就不那么適宜了。
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
在Struts Action 2.0我們希望：更好的文檔。支持標準（如果可以，我們希望用JSTL代替OGNL，但是首先要保證不會(huì )有功能損失）。增強AJAX支持，提供更多的widgets：如自動(dòng)完成。解除配置地獄；提供更多的選擇，如我們開(kāi)始所說(shuō)的CoC。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
他需要很多的配置：我已經(jīng)演示過(guò)，通過(guò)CoC風(fēng)格，它可以做的比Rails更好（Rails的管理部允許內嵌controllers）。
6、你對Ruby on Rails的看法如何？
非常重要的一點(diǎn)是，我要說(shuō)RoR不能與大多數的framework對比，除了RIFE和Seam。對比RoR和WebWork就相當于對比Hibernate和JDBC。一個(gè)是full stack，另一個(gè)只是stack中的一部分。
另一個(gè)重要的問(wèn)題：DHH是個(gè)怪胎，但是聰明的怪胎。它的高效率無(wú)可爭辯，它被稱(chēng)為Rails。
好的，我們不說(shuō)這個(gè)，隨便說(shuō)說(shuō)別的：
我使用Rails創(chuàng )建了一個(gè)小的app。我把它扔掉并很快用Java重寫(xiě)了。我認為Rails可以讓你的app中的80%快速完成；而剩下的20%比前面 80%需要花的時(shí)間還多。當然程序開(kāi)發(fā)就是這樣。腳手架非?？?，尤其是ActiveRecord在運行時(shí)改變類(lèi)。但是后來(lái)你需要寫(xiě)UI、自定義的驗證規則，自定義安全影射等等。一個(gè)基于CRUD的app能夠在30分鐘內運行并不意味著(zhù)你能以這個(gè)速度完成它。
Rails的web framework部分相比于WebWork很可怕。實(shí)際上根本無(wú)法比較。它的實(shí)現更接近于Spring MVC的簡(jiǎn)單功能。
完整的stack非常棒。他們在這方面做得很好，這里Java還有差距需要追趕。WebWork是web stack，但是持久化解決方案并不確定。所以最大的問(wèn)題在于即使WebWork和SiteMesh提供了如配置動(dòng)態(tài)讀取和動(dòng)態(tài)類(lèi)reloading， Spring、iBatis和Hibernate并不提供。它們至少需要提供配置重讀取后才可以發(fā)展出類(lèi)似Rails那樣的功能。類(lèi)似的， Hibernate和iBatis對WebWork等的請求提供的支持不夠。對于一個(gè)類(lèi)，我可以不需要再xwork.xml中進(jìn)行配置，但是持久化引擎并不允許我們這樣做。當這些功能能夠同時(shí)具備，沒(méi)準一個(gè)complete stack的框架就會(huì )推出。
要求快5倍10倍是愚蠢的?？煽康墓こ處煻贾篱_(kāi)發(fā)產(chǎn)品的時(shí)候最大的警力都花費在構思代碼上，而不是書(shū)寫(xiě)代碼。定義需求，獲取反饋，市場(chǎng)定位，定義數據庫結構，映射用戶(hù)接口。不管使用什么語(yǔ)言，你需要思考很長(cháng)時(shí)間。沒(méi)有語(yǔ)言或者框架能夠提升思考的速度。
最后，Rails提供了：用腳本語(yǔ)言良好實(shí)現的stack。Python、Perl尤其是PHP中的其它框架還沒(méi)有成熟。我認為“PHP猴子”們還有很多事情要做，他們通常不是很有才干的工程師。（可能我翻譯錯誤了，希望糾正）。在腳本語(yǔ)言中提供良好的框架，人們能夠實(shí)現設計精良的app并的到回報（因為腳本語(yǔ)言的特點(diǎn)）。不只是“管理代替配置CoC”甚至是集成stack，Java需要的是立刻反射出變化的能力。很多Java開(kāi)源領(lǐng)袖認為“修改 web.xml”的重新載入是一種方法。這種智力游戲應該結束了。我們不僅僅需要配置文件和類(lèi)的重新載入，我們需要社區給Sun足夠的壓力，使其能夠在下一代的JVM中提供熱插拔（HotSwap）的能力?；蛘?，更加復雜的程序模型，如OSGi，需要進(jìn)一布被社區所接受。當然我并不希望走那條路線(xiàn)。

Wicket(Eelco Hillenius)
1、你認為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類(lèi)型的項目？
我認為有5點(diǎn)：Wicket是以代碼為中心的：可以在view層進(jìn)行OO編程。組件是完全自管理的：容易創(chuàng )建和重用。概念的分離是清晰的也是強迫的。干凈的模版。開(kāi)發(fā)伸縮性大-就像OO一樣。
2、它不適合于什么樣的場(chǎng)景？在這些場(chǎng)景你推薦什么fremework？它是哪個(gè)？
Wicket不適合UI很簡(jiǎn)單且只讀的場(chǎng)合。這時(shí)頁(yè)面腳本更加適合，比如JSP，或者JSF。如果你需要無(wú)限的可伸縮性，你可能需要狀態(tài)無(wú)關(guān)的實(shí)現。從1.2版開(kāi)始，Wicket也有無(wú)狀態(tài)頁(yè)面的概念，這樣可伸縮性與其它framework差不多了。
3、在下面提到的framework中，你試驗過(guò)他們么？如果試驗過(guò)，你比較喜歡哪個(gè)？你不喜歡哪個(gè)？
JSF：
優(yōu)點(diǎn)：基于組件。工業(yè)背景。工具支持。一些擴展讓他更容易使用。它允許你從傳統JSP升級到JSF。
缺點(diǎn)：它缺少其它API的優(yōu)雅。以JSP為中心。配置很多而且代碼很難看。有很多種實(shí)現。它讓我回憶起EJB1/2，以廠(chǎng)商為中心等等。
RIFE：沒(méi)用過(guò)，說(shuō)了一大堆。
Seam：不是一個(gè)真正的Web framework。類(lèi)似JSF擴展。如果使用EJB/JSF/JBoss組合，這個(gè)選擇很好。但是不遵循JSR 227/235。
Tapestry：很好，4.0版本好了很多。我把它推薦給我所工作的公司。Wicket更加以編程為中心。而Tapestry更加pragmatic。
Trails：從來(lái)沒(méi)用過(guò)。
Spring Web Flow：framework本身很好，但是我不喜歡它的stacking。如果用工作流，我希望選擇一個(gè)如jBMP的方案。我也不喜歡以流為中心的解決方案，認為這樣很過(guò)程化。
WebWork、 Spring MVC、Struts：Model 2的framework糟透了。我用過(guò)幾年，也對Maverick貢獻過(guò)代碼，但是我徹底失去興趣了。Model 2 framework太過(guò)程化了，這些程序員不知道怎么用OO編程。我寧可雇傭一個(gè)Swing編程的人也不會(huì )去選擇一個(gè)使用Model 2 framework編程的人，因為Swing編程的人寫(xiě)的程序一般更漂亮?！绻屛覐倪@些Model 2 framework中挑一個(gè)出來(lái)，我選擇Stripes，它拋棄了model 2中的一些不好的方面。
4、你的framework的未來(lái)會(huì )怎樣？對于用戶(hù)開(kāi)發(fā)會(huì )有什么方便使用的變化？你會(huì )原生支持Ajax么？你們計劃支持它了么？
我們將會(huì )支持Java5。我們會(huì )增強Spring支持，復雜的權限認證支持，和基于角色的參考實(shí)現，還會(huì )提供原生AJAX支持，URL加載（nice URLs），無(wú)狀態(tài)頁(yè)等。
我們的市場(chǎng)占有率不高，但是用戶(hù)群在提高。我正在寫(xiě)“Wicket In Action”（Manning出版）正在籌劃中，今年夏天會(huì )出版。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個(gè)？
關(guān)于伸縮性的問(wèn)題是第一位的。程序的可伸縮型一般是由數據庫性能差或者緩存策略查詢(xún)優(yōu)化并發(fā)等問(wèn)題。服務(wù)器端可伸縮性并不一定不可擴展，可以通過(guò)集群來(lái)繼絕?！?br>6、你對Ruby on Rails的看法如何？
我喜歡我看到的Ruby，如果我有時(shí)間我還會(huì )仔細把玩它。如果不是Wicket的問(wèn)題，我希望更多的實(shí)踐RoR?！?