Jave Web Framework Sweet Spots
Java Web 框架的“甜點”
這是一篇很有趣的文檔，所以摘要一下，其實類似閱讀筆記，好像是3/25發(fā)布的：
不知怎么翻譯Sweet Spots，難道翻譯為甜處、甜頭、蜜點、蜜穴？
這時基于對以下人的采訪：
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、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
當(dāng)你希望瀏覽器程序像桌面程序一樣工作的時候，你可以遵循標(biāo)準(zhǔn)并獲得大量第三方支持。它致力于降低復(fù)雜度。它允許你不與view和特定的action、參數(shù)傳遞、狀態(tài)傳遞、渲染打交道就可以進(jìn)行高質(zhì)量的開發(fā)，不管是否使用工具。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
它不適合大規(guī)模的、只讀（其實指讀為主）的網(wǎng)站。在這種情況推薦Struts，因為知識庫豐富（應(yīng)該指文檔和用戶群）。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
Seam：
優(yōu)點：非常簡單直接
缺點：對于大項目過于簡單；沒有模塊化開發(fā)的好例子
Struts：
優(yōu)點：巨大的文檔和用戶群；跟著它沒錯
缺點：狀態(tài)/行為的分離過于教條化
WebWork：
優(yōu)點：比Struts易于使用
缺點：復(fù)雜的UI難于維護(hù)，UI代碼過于復(fù)雜（JSF作者對action Framework都攻擊這一點）
Tapestry：
優(yōu)點：概念新穎；可以應(yīng)付復(fù)雜的UI
缺點：對于一個組件化（JSF主要競爭對手），它依然依附于page/action的概念
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
他認(rèn)為JSF這個標(biāo)準(zhǔn)下這些應(yīng)該有第三方提供。JSF(2.0)會提供“Partial Faces Request”，它是Ajax實現(xiàn)。JSF也會增強(qiáng)annotation組建編程。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
很多JSF書都拿Struts作為對比。他認(rèn)為這不能體現(xiàn)JSF的特點。他認(rèn)為Struts和WebWork能做到的JSF也能做到。
6、你對Ruby on Rails的看法如何？
它與WebWork一樣好用，它的CoC（Convention over Configration）和腳手架非常好用。他認(rèn)為CoC可以被應(yīng)用在任何framework，他認(rèn)為這是RoR最大的優(yōu)點。他還認(rèn)為RoR會走上其它framework的路（復(fù)雜性等），因為人們需要自己的擴(kuò)展。
RIFE(Geert Bevin)
1、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
你可以付出10%的工作量，得到其它framework的90%的……，它是一個full-stack framework（如RoR）。它吸收了成熟的分層框架的架構(gòu)，并將共同的優(yōu)點匯集在一起。提供了web continuation，POJO驅(qū)動的CRUD生成，可擴(kuò)展的基于組建的架構(gòu)，無session的狀態(tài)控制，關(guān)注REST作為API，雙向無邏輯模版引擎，集成了內(nèi)容控制框架（CMS？）。每個層次的組建提供了可復(fù)用性（AOP，site，sub-site，page，widget，portlet等）。適合于團(tuán)隊快速開發(fā)公共Web項目，適合喜歡開發(fā)可復(fù)用組件的人。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
團(tuán)隊中的每個人都有其它framework的知識，難于培訓(xùn)他們。開發(fā)狀態(tài)相關(guān)的服務(wù)器端Web組件，而不是用RIA或Ajax去實現(xiàn)。第三方支持很重要的情況下（可憐RIFE用戶群還不大）。他推薦這種情況下使用JSF。或者在XML為主要發(fā)布形式的情況下，推薦Cocoon。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
他試驗過WebWork，JSF，Wicket。他喜歡WebWork的簡單，但是不喜歡它的模版方式（tag的template，應(yīng)該），它也不提供組件封裝。他認(rèn)為JSF的工具支持非常吸引人。Wicket的純Java實現(xiàn)很不錯，可惜XML配置很不爽。
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
關(guān)于Ajax，RIFE剛剛集成了DWR，而且選定以后也使用這個。集成Dojo，Scriptaculous，Prototype都很容易集成進(jìn)來。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
這些錯誤理念：1、RIFE的XML配置繁瑣 2、RIFE是continuations server 3、RIFE重新造輪子沒有提供新鮮東西 4、RIFE的模版語法很蹩腳過于簡單和業(yè)余 5、RIFE是基于request的framework 6、RIFE的功能太多，學(xué)習(xí)曲線陡峭
6、你對Ruby on Rails的看法如何？
RoR對Java社區(qū)的沖擊非常棒，元編成也得到了信任。RoR沒什么特殊之處，也沒有從Ruby語言獲益很多。
我討厭：它的模版。Partials（RoR中的組件）。URL的分散處理。Active Record提供了從數(shù)據(jù)庫schema而來的DSL，但是卻不是從domain model而來。沒有l(wèi)10n和i18n支持。手動狀態(tài)轉(zhuǎn)換。不能在JVM運(yùn)行（……）。實際上腳手架生成了實際代碼。Ruby缺少工具和IDE。
Seam(Gavin King)
1、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
擁有豐富用戶交互體驗的應(yīng)用。方便實現(xiàn)多窗口的操作，回退的支持，單窗口多工作區(qū)，無狀態(tài)瀏覽。對商務(wù)流程（BPM）的集成是獨(dú)一無二的。Seam方便使用數(shù)據(jù)驅(qū)動的ORM。遵循JSF和EJB3，多任務(wù)支持（多窗口/多工作區(qū)），BPM的領(lǐng)先解決方案。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
不適合只是將數(shù)據(jù)從數(shù)據(jù)庫顯示到網(wǎng)頁的應(yīng)用，這時應(yīng)該使用PHP或RoR。不適合需要設(shè)計特別的HTML組件的情況，此時應(yīng)該選用Tapestry或Wicket。還在使用JDK1.4的人們。還有那些喜歡Struts的人（嘿嘿，夠狠）。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
JSF：喜歡他的事件/交互模型。喜歡他的EL和模型綁定。不喜歡那么多XML（為什么沒有annotation）。創(chuàng)建自己的controls太難了。
Tapestry：非常好。form驗證是它的殺手锏！模版方式很有創(chuàng)意。不過非基于POJO的組件模型則讓我對它失去興趣。
RIFE：這個東西很怪，但是有創(chuàng)業(yè)也有趣。我想進(jìn)一步學(xué)習(xí)。如果學(xué)習(xí)先要自費(fèi)武功:D
Struts：這個東西的模型view綁定太復(fù)雜了。東西已經(jīng)過時了。
WebWork：比Struts好一點，不過也過時了。XWork曾經(jīng)是個很好的實現(xiàn)，不過現(xiàn)在也過時了。
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
Portal支持。遠(yuǎn)程框架Seam Remoting Framework（Ajax）。模版消息的工具支持。以后還要集成ESB，計劃引擎和異步支持。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
這些都不是真的：JSF不能處理GET requests。JSF post后無法redirect。JSF不能與REST共存。
6、你對Ruby on Rails的看法如何？
它是PHP的很好替代品。如果它有一個正經(jīng)一點的持久化層它就可以和Java競爭了。
Spring MVC(Rob Harrop)和Spring Web Flow(Rob Harrop and Keith Donald)
1、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
Spring MVC：
穩(wěn)定可擴(kuò)展，支持了i18n、文件上傳、異常處理，這些穩(wěn)定的支持給開發(fā)者堅實的工作基礎(chǔ)。是最佳實踐，告訴你怎么做是最好的。與Spring集成，領(lǐng)先的IoC遠(yuǎn)生支持。支持，Spring社區(qū)活躍和龐大。Struts開發(fā)者可以平滑過渡。適合多種項目，可選的多種result類型。
Spring Web Flow：
內(nèi)置任務(wù)處理引擎，支持線性處理過程中的持續(xù)狀態(tài)。抽象，減少開發(fā)的關(guān)注點。適合多種項目類型，插件支持Spring MVC、Struts、JSF等。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
Spring MVC：不適合需要組件化開發(fā)的場景。它是一個request驅(qū)動的MVC。那些場景推薦JSF或Tapestry。
Spring Web Flow：處理線性頁面流，不適合一般的“自由瀏覽”。當(dāng)然Spring Web Flow可以與request驅(qū)動或者組件驅(qū)動共存。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
Spring框架支持Struts和JSF集成。
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
Spring MVC：簡化JSP標(biāo)簽。更多的MVC配置schema。CoC風(fēng)格的默認(rèn)控制器、URL影射、view，學(xué)習(xí)Rails和Stripes的優(yōu)點。增強(qiáng)數(shù)據(jù)綁定和驗證（支持范型綁定）。Portlet支持。Spring也要接受Ajax，使用DWR庫。
Spring Web Flow：一大堆，關(guān)心的可以自己看……
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
Spring MVC難于配置。在Spring 2.0，將會改善，可以使用自己定義的基于schema的配置。
6、你對Ruby on Rails的看法如何？
Spring MVC：RoR非常有趣。不過現(xiàn)在就拿出來用還有點幼稚。這里舉了個例子，關(guān)于變量的復(fù)數(shù)形式的處理，RoR會使用這樣的CoC風(fēng)格來處理變量list，而Spring MVC也實驗了種種風(fēng)格，但是受到的結(jié)果卻很差。人們認(rèn)為英語的復(fù)數(shù)很古怪，沒有一定的規(guī)則，所以會帶來混亂，如（person -> people）。所以Spring MVC設(shè)計了變量+List的命名，personList更加明確，雖然這樣不酷，但更好用。就是說Spring MVC要取其精華去其糟粕。
Stripes(Tim Fennell)
1、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
與Spring MVC、WebWork等相同。它提供高質(zhì)量action驅(qū)動的框架的同時，盡量簡化配置，增進(jìn)開發(fā)效率。Stripes適合復(fù)雜的數(shù)據(jù)交互的場合。這種情況下綁定驗證的強(qiáng)項就完全體現(xiàn)出來了，能夠很好的處理form和map轉(zhuǎn)換等。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
所有的action驅(qū)動的framework都適合用戶在非Ajax驅(qū)動的情況下在一個頁面進(jìn)行松關(guān)聯(lián)（loosely related）和無狀態(tài)交互的情況。適合每次都刷新的頁面。管理多窗口間持續(xù)狀態(tài)的應(yīng)用會比較麻煩，此時應(yīng)該選擇JSF。不過我認(rèn)為90%以上的Web程序都是前者，JSF只適合剩下的那9%，AJAX對于管理無狀態(tài)UI更加適合。客戶端不需要AJAX，則可以看看Wicket，它更加簡單。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
用過Struts、WebWork、Spring MVC。其中Struts做過商業(yè)項目，不過這個東西帶來的麻煩遠(yuǎn)比帶來的效率提升要多。它認(rèn)為這些MVC都有三個缺點：暴露了過多的復(fù)雜性給可發(fā)者。沒有提供足夠的開發(fā)便利性，沒有提供足夠多的錯誤和提示信息，也沒有date格式化等小的便利（其實有）。穩(wěn)當(dāng)太差。
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
1.3要加入Inteceptor，實現(xiàn)AOP功能。驗證系統(tǒng)要加強(qiáng)。支持Ajax。我還在尋找一個好的Ajax/javascript庫。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
這些觀點：1、Stripes使用了annotation代替XML，只是換湯不換藥：由于元數(shù)據(jù)更接近代碼，所以修改默認(rèn)的配置非常方便，不像XML那樣復(fù)雜，這是實質(zhì)的變化。2、Annotation意味著你只能有一套配置：我認(rèn)為90%的action都有自己的一套配置！Stripes會根據(jù)繼承關(guān)系尋找Annotations，子類的annotation會覆蓋父類的，因為像validation都是可以繼承的，如果特別需要還可以覆蓋。這樣很合理。在1.3中允許validations基于UI事件進(jìn)行。它向后兼容，不需要可以不用。
6、你對Ruby on Rails的看法如何？
我認(rèn)為Java社區(qū)有很多可以從RoR學(xué)習(xí)的地方。Stripes學(xué)習(xí)了RoR的前端部分，開發(fā)者可以減少配置量。但是RoR的RHTML讓我想到了以前的JSP中混亂的scriptlet。而后面的ActiveRecord是一個很好的理念，實現(xiàn)的也很好。ActiveRecord比Hibernate等復(fù)雜的ORM工具要容易理解，因為這樣的特點RoR才引起了這么大的波瀾。
Struts Action 1(Don Brown)
1、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
文檔和用戶基礎(chǔ)，書籍和背后的支持。容易雇到人（也容易找工作）。雖然其他項目的理念比這個要先進(jìn)，但是這些不算什么。實際上，Web層是很容易也很直接的。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
如果你需要portlets或者復(fù)雜的頁面（顯示很多東西），那么Struts要么無法工作要么太枯燥。這種情況你需要一個基于組件的framework，如JSF、Tapestry/Wicket。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
這些我基本都試驗過，他們每個都工作的很不錯。
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
Struts Action 2基于WebWork2，很快會開始。現(xiàn)在已經(jīng)支持Ajax了，我們在尋找更加容易的開發(fā)方式，JSF支持（Struts Shale），continuation支持，還有支持更多的腳本語言（BSF擴(kuò)展腳本撰寫Action）。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
Struts太過時了，而且也不酷，難于使用。但是你可以自己修改或者擴(kuò)展它。我認(rèn)為團(tuán)隊對于你的限制遠(yuǎn)大于framework對你的限制。
6、你對Ruby on Rails的看法如何？
不需要D&D工具，旨在幫助開發(fā)人員提高開發(fā)效率的好例子。我們在Action 2中將學(xué)習(xí)它的先進(jìn)理念。
Tapestry(Howard Lewis Ship)
1、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
我想Tapestry對于中等規(guī)模或者大規(guī)模的應(yīng)用會帶來很多好處（甚至你可以在單頁面的應(yīng)用程序中獲得好處）。這里有允許你創(chuàng)建新的組件的良好工具。Tapestry不關(guān)心數(shù)據(jù)從哪里來，很多“項目類型”都基于切面（aspect）（如CRUD vs. RSS feed vs. etc.）。我認(rèn)為Tapestry非常容易與IoC集成（HiveMind或與Spring），方便進(jìn)行測試。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
我在其它Java framework中沒有找到到強(qiáng)于Tapestry的優(yōu)點。但是對于RoR，我自己沒有使用過使用，很難說RoR中的項目應(yīng)該是什么樣子。我沒有仔細(xì)對比過RIFE，它看起來受了RoR影響，尤其是類似ActiveRecord的數(shù)據(jù)訪問層。但是如果你的應(yīng)用需要特定的URL格式，那么在Tapestry中奮戰(zhàn)勝算不大。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
在這兩年來我沒怎么嘗試過Tapestry以外的東西。我沒怎么學(xué)習(xí)RoR，因為時間太有限了。
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
Tapestry 4.0有很好的Ajax支持，通過Tacos庫。而Tapestry 4.1還要進(jìn)一步強(qiáng)化這方面的支持。
Tapestry 5.0提供了明顯的改進(jìn)：沒有abstract類（Tapestry的怪癖:）。沒有強(qiáng)迫的繼承關(guān)系。對屬性進(jìn)行annotation而不是方法。沒有XML，只有模版和annotaions。只能類裝載，自動尋找類的變化。最小化API，超越annotaion。面向方面（Aspect-oriented）模塊構(gòu)造，使用mix-ins。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
Tapestry 3.0還不容易測試，4.0改善了一些。Tapestry只是個人秀；實際上我們有很多活躍的貢獻(xiàn)者。Tapestry的學(xué)習(xí)曲線非場陡峭。它只有漂亮的模版實現(xiàn)；實際上Tapestry的特點在于狀態(tài)管理（允許對象存儲狀態(tài)，而不是多線程的單例來管理requests之間的游離和持久狀態(tài)）
6、你對Ruby on Rails的看法如何？
很有影響力。但是模版的實現(xiàn)非常丑陋。我聽到了很多意見，關(guān)于RoR的優(yōu)缺點。基于我的基本理解，這些觀念對Tapestry 4產(chǎn)生了影響（它對Tapestry 5影響更深）。
RoR意味著限制了你的選擇：如果你選擇RoR那么就要尊旬它的實踐（CoC..），看起來你的錢會花的恨值。這些類似Microsoft的哲學(xué)。而Java更崇尚給你更寬松的選擇，不限定你使用的工具，但是曖昧的說這需要你對你的工具理解更深。不僅對Tapestry，還對于JEE、Spring這寫entire stack的框架，需要從RoR學(xué)習(xí)，不僅提供工具，還需要提供整套的解決方案。
Trails(Chris Nelson)
1、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
Trails的應(yīng)用程序只需要Web界面和持久化的domain model就可以了。Trails給你的domain model快速的提供一個界面，除了POJO自己不需要附加的代碼。Trails允許你修改界面的外觀和行為，包括驗證、i18n、安全。這些都不需要java代碼生成，不喜歡代碼生成的人應(yīng)該感覺很舒適。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
Trails講究夠用就好。它允許你快速交付，問問你的客戶：“這樣夠好么？”。這會改變你的工作流程，當(dāng)然這不是可以覆蓋所有需求的解決方案。當(dāng)UI需求很高，Trails沒有優(yōu)勢。我認(rèn)為Trails適合于混合的應(yīng)用，對于管理員他們只需要夠用就好，那么就可以使用Trails。其它的部分我們可以訂制開發(fā)，我們在使用Tapestry、Hibernate、Spring來實現(xiàn)這些部分，Trails正是基于它們。對于非交互的應(yīng)用，Trails也不適合，如報表應(yīng)用，可以考慮Eclipse BIRT。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
我用Struts很多。它曾經(jīng)是偉大的framework。主要的缺陷是它不能自動幫定數(shù)據(jù)到domain model。我也研究過JSF，它比Struts強(qiáng)，但是自定義組建非常難。Tapestry非常便于自定義組建，尤其對于建立高階組件（有其它組件組成的）非常方便，Trails正在使用它。
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
對于Trails來說我們站在巨人的肩膀上。Tapestry在ajax功能作了很多努力，所以Trails也不難與其共舞。但是我們需要創(chuàng)建更多的例子來演示這些。我們也致力于讓Trails容易介入到已經(jīng)進(jìn)行的項目中。以后Trails還要加入基于實例的安全（instance-based security）（目前正在使用基于角色的role-based），還有method invocation。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
Trails是對RoR的移植。Trails的名字來自Rails。它是基于Rails的理念，但不是對它的移植。
6、你對Ruby on Rails的看法如何？
我認(rèn)為我們有很多需要從RoR學(xué)習(xí)的地方，那將幫助我們享受開發(fā)Web程序的愜意。
WebWork(Patrick Lightbody)
1、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
一般來說，WebWork一般適合小的團(tuán)隊，它們愿意保持一雙臟手，學(xué)習(xí)開元工具如何使用。WebWork不面向“輪椅程序員”，那些人只喜歡拖拽式的開發(fā)。WebWork給花時間學(xué)習(xí)它的人回報。例如，直到輸入和輸出的人（閱讀了參考文檔，那樣很好）能夠容易的創(chuàng)建ActionMapper和Configuration實現(xiàn)來提供“慣例”代替配置（CoC）的方便。我最近的例子中，URL是這樣“/project/123/suite/456/test/create”影射到“com.autoriginate.actions.project.suite.test.CreateAction”，然后自動的傳遞參數(shù)：projectId=123、suiteId=456。而Result是“[action].jsp”或者“[action]-[result].jsp”，也可以通過annotation來配置。
也就是說，WebWork是你的應(yīng)用程序framework中的最佳基礎(chǔ)工具。在這種情況以外也很好，但是目前不算最佳的“甜點”。
除去這些一般的，WebWork對于正在創(chuàng)建需要插件和擴(kuò)展的產(chǎn)品的人是必備的。例如JIRA、Confluence、Jive Forums。因為WebWork支持廣泛的模版語言（Velociy和FreeMarker），完整的tag支持，模塊寫好后非常容易插入。一個jar包就可以包括所有的action和view（得益于ftl的classpath支持）。最終的效果很好：在Confluence中你可以通過管理界面上傳一個jar，這個plug-in就會自動部署。這是因為Atlassian（Confluence、Jira的小組）非常了解這個framework，并且作了很多的貢獻(xiàn)。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
與其它action framework相同，WebWork在控制狀態(tài)和wizards上比較弱。如果你寫了很多長的wizards，JSF可能是比較好的解決方案。我還想說，文檔還需要改善（參考文檔還不錯，但是教程、cookbooks和FAQ還比較差），如果沒有一個WebWork高手作為項目領(lǐng)隊，新手可能會敬而遠(yuǎn)之。
對于非常簡單的程序，我推薦使用簡單的JSP或者Spring MVC，如果用戶接受Spring的話。但是總的來說，我認(rèn)為在action framework中WebWork是最好的。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
我試驗過RIFE、Spring MVC、Struts、Spring Web Flow，還有一點點Tapestry。我發(fā)現(xiàn)RIFE的概念很優(yōu)秀，但是它的實現(xiàn)不怎么樣。不難想象Geert還是使用“m_”作為字段的前綴。它看起來不像Java。模版難住了我，所以就沒有繼續(xù)看。
Spring MVC還可以，但是它是一個非常簡單的framework實現(xiàn)。WebWork的數(shù)據(jù)綁定（WebWork世界中稱為類型轉(zhuǎn)換）要強(qiáng)多了，而且是自動的（而Spring需要自己寫property editors）。在Spring中的view替換支持泰有限了，而WebWork中的UI tags在Spring中壓根沒有提供。Spring中你可以使用JSP 2.0輕松的寫自己的tag，但是不支持其它的語言。
Spring Web Flow：XML讓我抓狂。太過火了，不管Keith的主張，它“不支持任何的Web framework”。這個web framwork回避掉了WebWork、Spring MVC、Struts或者其它framework中的99%。我倒不是說這是個壞主意，但是我應(yīng)該誠實的說它是一個完整的框架。
Tapestry很優(yōu)雅，但是HTML屬性（jwcid）惹人厭。我接受這種理念，且實踐中這會帶來一些好處（Shale也有相似的地方）。但是實際上，我發(fā)現(xiàn)“HTML/CSS開發(fā)者”和“app開發(fā)者”一般是同一個人，Tapestry就架設(shè)如此。實際上，由于Ajax的推動，我想越來越多的“程序邏輯”會被嵌入到UI；這樣的話，Tapestry的模型就不那么適宜了。
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
在Struts Action 2.0我們希望：更好的文檔。支持標(biāo)準(zhǔn)（如果可以，我們希望用JSTL代替OGNL，但是首先要保證不會有功能損失）。增強(qiáng)AJAX支持，提供更多的widgets：如自動完成。解除配置地獄；提供更多的選擇，如我們開始所說的CoC。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
他需要很多的配置：我已經(jīng)演示過，通過CoC風(fēng)格，它可以做的比Rails更好（Rails的管理部允許內(nèi)嵌controllers）。
6、你對Ruby on Rails的看法如何？
非常重要的一點是，我要說RoR不能與大多數(shù)的framework對比，除了RIFE和Seam。對比RoR和WebWork就相當(dāng)于對比Hibernate和JDBC。一個是full stack，另一個只是stack中的一部分。
另一個重要的問題：DHH是個怪胎，但是聰明的怪胎。它的高效率無可爭辯，它被稱為Rails。
好的，我們不說這個，隨便說說別的：
我使用Rails創(chuàng)建了一個小的app。我把它扔掉并很快用Java重寫了。我認(rèn)為Rails可以讓你的app中的80%快速完成；而剩下的20%比前面80%需要花的時間還多。當(dāng)然程序開發(fā)就是這樣。腳手架非常酷，尤其是ActiveRecord在運(yùn)行時改變類。但是后來你需要寫UI、自定義的驗證規(guī)則，自定義安全影射等等。一個基于CRUD的app能夠在30分鐘內(nèi)運(yùn)行并不意味著你能以這個速度完成它。
Rails的web framework部分相比于WebWork很可怕。實際上根本無法比較。它的實現(xiàn)更接近于Spring MVC的簡單功能。
完整的stack非常棒。他們在這方面做得很好，這里Java還有差距需要追趕。WebWork是web stack，但是持久化解決方案并不確定。所以最大的問題在于即使WebWork和SiteMesh提供了如配置動態(tài)讀取和動態(tài)類reloading，Spring、iBatis和Hibernate并不提供。它們至少需要提供配置重讀取后才可以發(fā)展出類似Rails那樣的功能。類似的，Hibernate和iBatis對WebWork等的請求提供的支持不夠。對于一個類，我可以不需要再xwork.xml中進(jìn)行配置，但是持久化引擎并不允許我們這樣做。當(dāng)這些功能能夠同時具備，沒準(zhǔn)一個complete stack的框架就會推出。
要求快5倍10倍是愚蠢的。可靠的工程師都知道開發(fā)產(chǎn)品的時候最大的警力都花費(fèi)在構(gòu)思代碼上，而不是書寫代碼。定義需求，獲取反饋，市場定位，定義數(shù)據(jù)庫結(jié)構(gòu)，映射用戶接口。不管使用什么語言，你需要思考很長時間。沒有語言或者框架能夠提升思考的速度。
最后，Rails提供了：用腳本語言良好實現(xiàn)的stack。Python、Perl尤其是PHP中的其它框架還沒有成熟。我認(rèn)為“PHP猴子”們還有很多事情要做，他們通常不是很有才干的工程師。（可能我翻譯錯誤了，希望糾正）。在腳本語言中提供良好的框架，人們能夠?qū)崿F(xiàn)設(shè)計精良的app并的到回報（因為腳本語言的特點）。不只是“管理代替配置CoC”甚至是集成stack，Java需要的是立刻反射出變化的能力。很多Java開源領(lǐng)袖認(rèn)為“修改web.xml”的重新載入是一種方法。這種智力游戲應(yīng)該結(jié)束了。我們不僅僅需要配置文件和類的重新載入，我們需要社區(qū)給Sun足夠的壓力，使其能夠在下一代的JVM中提供熱插拔（HotSwap）的能力。或者，更加復(fù)雜的程序模型，如OSGi，需要進(jìn)一布被社區(qū)所接受。當(dāng)然我并不希望走那條路線。
Wicket(Eelco Hillenius)
1、你認(rèn)為你的framework的“甜點”在哪里？他最適合哪種類型的項目？
我認(rèn)為有5點：Wicket是以代碼為中心的：可以在view層進(jìn)行OO編程。組件是完全自管理的：容易創(chuàng)建和重用。概念的分離是清晰的也是強(qiáng)迫的。干凈的模版。開發(fā)伸縮性大-就像OO一樣。
2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
Wicket不適合UI很簡單且只讀的場合。這時頁面腳本更加適合，比如JSP，或者JSF。如果你需要無限的可伸縮性，你可能需要狀態(tài)無關(guān)的實現(xiàn)。從1.2版開始，Wicket也有無狀態(tài)頁面的概念，這樣可伸縮性與其它framework差不多了。
3、在下面提到的framework中，你試驗過他們么？如果試驗過，你比較喜歡哪個？你不喜歡哪個？
JSF：
優(yōu)點：基于組件。工業(yè)背景。工具支持。一些擴(kuò)展讓他更容易使用。它允許你從傳統(tǒng)JSP升級到JSF。
缺點：它缺少其它API的優(yōu)雅。以JSP為中心。配置很多而且代碼很難看。有很多種實現(xiàn)。它讓我回憶起EJB1/2，以廠商為中心等等。
RIFE：沒用過，說了一大堆。
Seam：不是一個真正的Web framework。類似JSF擴(kuò)展。如果使用EJB/JSF/JBoss組合，這個選擇很好。但是不遵循JSR 227/235。
Tapestry：很好，4.0版本好了很多。我把它推薦給我所工作的公司。Wicket更加以編程為中心。而Tapestry更加pragmatic。
Trails：從來沒用過。
Spring Web Flow：framework本身很好，但是我不喜歡它的stacking。如果用工作流，我希望選擇一個如jBMP的方案。我也不喜歡以流為中心的解決方案，認(rèn)為這樣很過程化。
WebWork、Spring MVC、Struts：Model 2的framework糟透了。我用過幾年，也對Maverick貢獻(xiàn)過代碼，但是我徹底失去興趣了。Model 2 framework太過程化了，這些程序員不知道怎么用OO編程。我寧可雇傭一個Swing編程的人也不會去選擇一個使用Model 2 framework編程的人，因為Swing編程的人寫的程序一般更漂亮。……如果讓我從這些Model 2 framework中挑一個出來，我選擇Stripes，它拋棄了model 2中的一些不好的方面。
4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計劃支持它了么？
我們將會支持Java5。我們會增強(qiáng)Spring支持，復(fù)雜的權(quán)限認(rèn)證支持，和基于角色的參考實現(xiàn)，還會提供原生AJAX支持，URL加載（nice URLs），無狀態(tài)頁等。
我們的市場占有率不高，但是用戶群在提高。我正在寫“Wicket In Action”（Manning出版）正在籌劃中，今年夏天會出版。
5、有對你們的framework的傳言需要澄清么？如果有，是哪個？
關(guān)于伸縮性的問題是第一位的。程序的可伸縮型一般是由數(shù)據(jù)庫性能差或者緩存策略查詢優(yōu)化并發(fā)等問題。服務(wù)器端可伸縮性并不一定不可擴(kuò)展，可以通過集群來繼絕。……
6、你對Ruby on Rails的看法如何？
我喜歡我看到的Ruby，如果我有時間我還會仔細(xì)把玩它。如果不是Wicket的問題，我希望更多的實踐RoR。……