首先创建RomeResult类：

程序很简单。实现了Result接口，寻找一个与feedName参数匹配的SyndFeed实例，然后转换为指定的feedType类型，然后通过rome的SyndFeedOutput输出到Response去。
然后我们给我们的WebWork配置romeResult。
在xwork.xml中配置：

< package  name ="default"  extends ="webwork-default" >
   < result-types >
    < result-type  name ="feed"  class ="com.goldnet.framework.webwork.result.RomeResult" />
   </ result-types >
   < interceptors >
   <!--  然后是你的那些inteceptor配置等  -->

这样我们就给xwork配置了一个叫做feed的result，它就是我们的romeResult。
然后我们实现一个类，来测试一下这个romeResult。

真是不好意思，Getter/Setter占了大部分地方我省略去了。逻辑很简单，就是把我们的POJO影射到Feed的模型上面，过程很简单。我留下了几个参数可以在外面设置：
maxEntryNumber显示的feed的条数，链接生成时使用的SiteUrl，当然也可以通过request获取。
下面我们配置我们的Action，注意平时我们可能使用DAO生成newsList，而不是我这个写死的getNewsList()方法，此时可能需要配合Spring进行IOC的设置，我们这里省略掉。
下面是我们这个Action的xwork配置：

< package  name ="news"  extends ="default"  namespace ="/news" >
   < action  name ="feed"  class ="com.goldnet.webwork.action.news.TestFeedCreateAction" >
    <!--  每次生成15条rss feed  -->
    < param  name ="maxEntryNumber" > 15 </ param >
    <!--  链接的前缀，我们使用Weblogic是7001，也许你的是8080  -->
    < param  name ="siteUrl" > http://127.0.0.1:7001 </ param >
    <!--  result是feed  -->
    < result  name ="success"  type ="feed" >
     <!--  feed名字是feed，对应我们这个Action中的那个SyndFeed的实例的名字feed，别忘记写getter  -->
     < param  name ="feedName" > feed </ param >
     <!--  制定生成的feed的类型，我这里选择rss_2.0  -->
     <!--  rome 0.8支持atom_0.3、atom_1.0、rss_1.0、rss_2.0、rss_0.90、rss_0.91、rss_0.91、rss_0.91U、rss_0.92、rss_0.93、rss_0.94  -->
     < param  name ="feedType" > rss_2.0 </ param >
    </ result >
   </ action >
</ package >

OK，配置完毕后访问/news/feed.action就可以访问到这个feed了。倒入你的feedDeamon，看看，是不是非常简单？
不过需要考虑两个地方，一个是编码问题，看了和东说的中文问题，本没当回事，结果生成乱码（我们项目全部使用UTF-8），然后还是转了一下。没有研究ROME源代码，感觉xml不应该有UTF-8还会乱码的问题呀，也许还需要看看是否是设置不到位。还有就是对于feed如果增加了权限认证则访问比较麻烦，用feedDeamon这样的客户端就无法访问到了，因为它不会显示登陆失败后显示的登陆页面，也许放feed就要开放一点吧（当然还是有变通放案的）。
和动例子里面的rome 0.7和现在的rome 0.8相比，Api已经发生了不少变化，唉，开源要代码稳定还真难。
就这些，就到这里，粗陋了:D

这是一篇很有趣的文档，所以摘要一下，其实类似阅读笔记，好像是3/25发布的：

不知怎么翻译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、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
当你希望浏览器程序像桌面程序一样工作的时候，你可以遵循标准并获得大量第三方支持。它致力于降低复杂度。它允许你不与view和特定的action、参数传递、状态传递、渲染打交道就可以进行高质量的开发，不管是否使用工具。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
它不适合大规模的、只读（其实指读为主）的网站。在这种情况推荐Struts，因为知识库丰富（应该指文档和用户群）。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
Seam：
优点：非常简单直接
缺点：对于大项目过于简单；没有模块化开发的好例子
Struts：
优点：巨大的文档和用户群；跟着它没错
缺点：状态/行为的分离过于教条化
WebWork：
优点：比Struts易于使用
缺点：复杂的UI难于维护，UI代码过于复杂（JSF作者对action Framework都攻击这一点）
Tapestry：
优点：概念新颖；可以应付复杂的UI
缺点：对于一个组件化（JSF主要竞争对手），它依然依附于page/action的概念
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
他认为JSF这个标准下这些应该有第三方提供。JSF(2.0)会提供“Partial Faces Request”，它是Ajax实现。JSF也会增强annotation组建编程。
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
很多JSF书都拿Struts作为对比。他认为这不能体现JSF的特点。他认为Struts和WebWork能做到的JSF也能做到。
6、你对Ruby on Rails的看法如何？
它与WebWork一样好用，它的CoC（Convention over Configration）和脚手架非常好用。他认为CoC可以被应用在任何framework，他认为这是RoR最大的优点。他还认为RoR会走上其它framework的路（复杂性等），因为人们需要自己的扩展。

RIFE(Geert Bevin)
1、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
你可以付出10%的工作量，得到其它framework的90%的……，它是一个full-stack framework（如RoR）。它吸收了成熟的分层框架的架构，并将共同的优点汇集在一起。提供了web continuation，POJO驱动的CRUD生成，可扩展的基于组建的架构，无session的状态控制，关注REST作为API，双向无逻辑模版引擎，集成了内容控制框架（CMS？）。每个层次的组建提供了可复用性（AOP，site，sub-site，page，widget，portlet等）。适合于团队快速开发公共Web项目，适合喜欢开发可复用组件的人。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
团队中的每个人都有其它framework的知识，难于培训他们。开发状态相关的服务器端Web组件，而不是用RIA或Ajax去实现。第三方支持很重要的情况下（可怜RIFE用户群还不大）。他推荐这种情况下使用JSF。或者在XML为主要发布形式的情况下，推荐Cocoon。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
他试验过WebWork，JSF，Wicket。他喜欢WebWork的简单，但是不喜欢它的模版方式（tag的template，应该），它也不提供组件封装。他认为JSF的工具支持非常吸引人。Wicket的纯Java实现很不错，可惜XML配置很不爽。
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
关于Ajax，RIFE刚刚集成了DWR，而且选定以后也使用这个。集成Dojo，Scriptaculous，Prototype都很容易集成进来。
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
这些错误理念：1、RIFE的XML配置繁琐 2、RIFE是continuations server 3、RIFE重新造轮子没有提供新鲜东西 4、RIFE的模版语法很蹩脚过于简单和业余 5、RIFE是基于request的framework 6、RIFE的功能太多，学习曲线陡峭
6、你对Ruby on Rails的看法如何？
RoR对Java社区的冲击非常棒，元编成也得到了信任。RoR没什么特殊之处，也没有从Ruby语言获益很多。
我讨厌：它的模版。Partials（RoR中的组件）。URL的分散处理。Active Record提供了从数据库schema而来的DSL，但是却不是从domain model而来。没有l10n和i18n支持。手动状态转换。不能在JVM运行（……）。实际上脚手架生成了实际代码。Ruby缺少工具和IDE。

Seam(Gavin King)
1、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
拥有丰富用户交互体验的应用。方便实现多窗口的操作，回退的支持，单窗口多工作区，无状态浏览。对商务流程（BPM）的集成是独一无二的。Seam方便使用数据驱动的ORM。遵循JSF和EJB3，多任务支持（多窗口/多工作区），BPM的领先解决方案。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
不适合只是将数据从数据库显示到网页的应用，这时应该使用PHP或RoR。不适合需要设计特别的HTML组件的情况，此时应该选用Tapestry或Wicket。还在使用JDK1.4的人们。还有那些喜欢Struts的人（嘿嘿，够狠）。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
JSF：喜欢他的事件/交互模型。喜欢他的EL和模型绑定。不喜欢那么多XML（为什么没有annotation）。创建自己的controls太难了。
Tapestry：非常好。form验证是它的杀手锏！模版方式很有创意。不过非基于POJO的组件模型则让我对它失去兴趣。
RIFE：这个东西很怪，但是有创业也有趣。我想进一步学习。如果学习先要自费武功:D
Struts：这个东西的模型view绑定太复杂了。东西已经过时了。
WebWork：比Struts好一点，不过也过时了。XWork曾经是个很好的实现，不过现在也过时了。
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
Portal支持。远程框架Seam Remoting Framework（Ajax）。模版消息的工具支持。以后还要集成ESB，计划引擎和异步支持。
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
这些都不是真的：JSF不能处理GET requests。JSF post后无法redirect。JSF不能与REST共存。
6、你对Ruby on Rails的看法如何？
它是PHP的很好替代品。如果它有一个正经一点的持久化层它就可以和Java竞争了。

Spring MVC(Rob Harrop)和Spring Web Flow(Rob Harrop and Keith Donald)
1、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
Spring MVC：
稳定可扩展，支持了i18n、文件上传、异常处理，这些稳定的支持给开发者坚实的工作基础。是最佳实践，告诉你怎么做是最好的。与Spring集成，领先的IoC远生支持。支持，Spring社区活跃和庞大。Struts开发者可以平滑过渡。适合多种项目，可选的多种result类型。
Spring Web Flow：
内置任务处理引擎，支持线性处理过程中的持续状态。抽象，减少开发的关注点。适合多种项目类型，插件支持Spring MVC、Struts、JSF等。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
Spring MVC：不适合需要组件化开发的场景。它是一个request驱动的MVC。那些场景推荐JSF或Tapestry。
Spring Web Flow：处理线性页面流，不适合一般的“自由浏览”。当然Spring Web Flow可以与request驱动或者组件驱动共存。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
Spring框架支持Struts和JSF集成。
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
Spring MVC：简化JSP标签。更多的MVC配置schema。CoC风格的默认控制器、URL影射、view，学习Rails和Stripes的优点。增强数据绑定和验证（支持范型绑定）。Portlet支持。Spring也要接受Ajax，使用DWR库。
Spring Web Flow：一大堆，关心的可以自己看……
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
Spring MVC难于配置。在Spring 2.0，将会改善，可以使用自己定义的基于schema的配置。
6、你对Ruby on Rails的看法如何？
Spring MVC：RoR非常有趣。不过现在就拿出来用还有点幼稚。这里举了个例子，关于变量的复数形式的处理，RoR会使用这样的CoC风格来处理变量list，而Spring MVC也实验了种种风格，但是受到的结果却很差。人们认为英语的复数很古怪，没有一定的规则，所以会带来混乱，如（person -> people）。所以Spring MVC设计了变量+List的命名，personList更加明确，虽然这样不酷，但更好用。就是说Spring MVC要取其精华去其糟粕。

Stripes(Tim Fennell)
1、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
与Spring MVC、WebWork等相同。它提供高质量action驱动的框架的同时，尽量简化配置，增进开发效率。Stripes适合复杂的数据交互的场合。这种情况下绑定验证的强项就完全体现出来了，能够很好的处理form和map转换等。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
所有的action驱动的framework都适合用户在非Ajax驱动的情况下在一个页面进行松关联（loosely related）和无状态交互的情况。适合每次都刷新的页面。管理多窗口间持续状态的应用会比较麻烦，此时应该选择JSF。不过我认为90%以上的Web程序都是前者，JSF只适合剩下的那9%，AJAX对于管理无状态UI更加适合。客户端不需要AJAX，则可以看看Wicket，它更加简单。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
用过Struts、WebWork、Spring MVC。其中Struts做过商业项目，不过这个东西带来的麻烦远比带来的效率提升要多。它认为这些MVC都有三个缺点：暴露了过多的复杂性给可发者。没有提供足够的开发便利性，没有提供足够多的错误和提示信息，也没有date格式化等小的便利（其实有）。稳当太差。
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
1.3要加入Inteceptor，实现AOP功能。验证系统要加强。支持Ajax。我还在寻找一个好的Ajax/javascript库。
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
这些观点：1、Stripes使用了annotation代替XML，只是换汤不换药：由于元数据更接近代码，所以修改默认的配置非常方便，不像XML那样复杂，这是实质的变化。2、Annotation意味着你只能有一套配置：我认为90%的action都有自己的一套配置！Stripes会根据继承关系寻找Annotations，子类的annotation会覆盖父类的，因为像validation都是可以继承的，如果特别需要还可以覆盖。这样很合理。在1.3中允许validations基于UI事件进行。它向后兼容，不需要可以不用。
6、你对Ruby on Rails的看法如何？
我认为Java社区有很多可以从RoR学习的地方。Stripes学习了RoR的前端部分，开发者可以减少配置量。但是RoR的RHTML让我想到了以前的JSP中混乱的scriptlet。而后面的ActiveRecord是一个很好的理念，实现的也很好。ActiveRecord比Hibernate等复杂的ORM工具要容易理解，因为这样的特点RoR才引起了这么大的波澜。

Struts Action 1(Don Brown)
1、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
文档和用户基础，书籍和背后的支持。容易雇到人（也容易找工作）。虽然其他项目的理念比这个要先进，但是这些不算什么。实际上，Web层是很容易也很直接的。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
如果你需要portlets或者复杂的页面（显示很多东西），那么Struts要么无法工作要么太枯燥。这种情况你需要一个基于组件的framework，如JSF、Tapestry/Wicket。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
这些我基本都试验过，他们每个都工作的很不错。
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
Struts Action 2基于WebWork2，很快会开始。现在已经支持Ajax了，我们在寻找更加容易的开发方式，JSF支持（Struts Shale），continuation支持，还有支持更多的脚本语言（BSF扩展脚本撰写Action）。
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
Struts太过时了，而且也不酷，难于使用。但是你可以自己修改或者扩展它。我认为团队对于你的限制远大于framework对你的限制。
6、你对Ruby on Rails的看法如何？
不需要D&D工具，旨在帮助开发人员提高开发效率的好例子。我们在Action 2中将学习它的先进理念。

Tapestry(Howard Lewis Ship)
1、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
我想Tapestry对于中等规模或者大规模的应用会带来很多好处（甚至你可以在单页面的应用程序中获得好处）。这里有允许你创建新的组件的良好工具。Tapestry不关心数据从哪里来，很多“项目类型”都基于切面（aspect）（如CRUD vs. RSS feed vs. etc.）。我认为Tapestry非常容易与IoC集成（HiveMind或与Spring），方便进行测试。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
我在其它Java framework中没有找到到强于Tapestry的优点。但是对于RoR，我自己没有使用过使用，很难说RoR中的项目应该是什么样子。我没有仔细对比过RIFE，它看起来受了RoR影响，尤其是类似ActiveRecord的数据访问层。但是如果你的应用需要特定的URL格式，那么在Tapestry中奋战胜算不大。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
在这两年来我没怎么尝试过Tapestry以外的东西。我没怎么学习RoR，因为时间太有限了。
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
Tapestry 4.0有很好的Ajax支持，通过Tacos库。而Tapestry 4.1还要进一步强化这方面的支持。
Tapestry 5.0提供了明显的改进：没有abstract类（Tapestry的怪癖:）。没有强迫的继承关系。对属性进行annotation而不是方法。没有XML，只有模版和annotaions。只能类装载，自动寻找类的变化。最小化API，超越annotaion。面向方面（Aspect-oriented）模块构造，使用mix-ins。
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
Tapestry 3.0还不容易测试，4.0改善了一些。Tapestry只是个人秀；实际上我们有很多活跃的贡献者。Tapestry的学习曲线非场陡峭。它只有漂亮的模版实现；实际上Tapestry的特点在于状态管理（允许对象存储状态，而不是多线程的单例来管理requests之间的游离和持久状态）
6、你对Ruby on Rails的看法如何？
很有影响力。但是模版的实现非常丑陋。我听到了很多意见，关于RoR的优缺点。基于我的基本理解，这些观念对Tapestry 4产生了影响（它对Tapestry 5影响更深）。
RoR意味着限制了你的选择：如果你选择RoR那么就要尊旬它的实践（CoC..），看起来你的钱会花的恨值。这些类似Microsoft的哲学。而Java更崇尚给你更宽松的选择，不限定你使用的工具，但是暧昧的说这需要你对你的工具理解更深。不仅对Tapestry，还对于JEE、Spring这写entire stack的框架，需要从RoR学习，不仅提供工具，还需要提供整套的解决方案。

Trails(Chris Nelson)
1、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
Trails的应用程序只需要Web界面和持久化的domain model就可以了。Trails给你的domain model快速的提供一个界面，除了POJO自己不需要附加的代码。Trails允许你修改界面的外观和行为，包括验证、i18n、安全。这些都不需要java代码生成，不喜欢代码生成的人应该感觉很舒适。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
Trails讲究够用就好。它允许你快速交付，问问你的客户：“这样够好么？”。这会改变你的工作流程，当然这不是可以覆盖所有需求的解决方案。当UI需求很高，Trails没有优势。我认为Trails适合于混合的应用，对于管理员他们只需要够用就好，那么就可以使用Trails。其它的部分我们可以订制开发，我们在使用Tapestry、Hibernate、Spring来实现这些部分，Trails正是基于它们。对于非交互的应用，Trails也不适合，如报表应用，可以考虑Eclipse BIRT。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
我用Struts很多。它曾经是伟大的framework。主要的缺陷是它不能自动帮定数据到domain model。我也研究过JSF，它比Struts强，但是自定义组建非常难。Tapestry非常便于自定义组建，尤其对于建立高阶组件（有其它组件组成的）非常方便，Trails正在使用它。
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
对于Trails来说我们站在巨人的肩膀上。Tapestry在ajax功能作了很多努力，所以Trails也不难与其共舞。但是我们需要创建更多的例子来演示这些。我们也致力于让Trails容易介入到已经进行的项目中。以后Trails还要加入基于实例的安全（instance-based security）（目前正在使用基于角色的role-based），还有method invocation。
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
Trails是对RoR的移植。Trails的名字来自Rails。它是基于Rails的理念，但不是对它的移植。
6、你对Ruby on Rails的看法如何？
我认为我们有很多需要从RoR学习的地方，那将帮助我们享受开发Web程序的惬意。

WebWork(Patrick Lightbody)
1、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
一般来说，WebWork一般适合小的团队，它们愿意保持一双脏手，学习开元工具如何使用。WebWork不面向“轮椅程序员”，那些人只喜欢拖拽式的开发。WebWork给花时间学习它的人回报。例如，直到输入和输出的人（阅读了参考文档，那样很好）能够容易的创建ActionMapper和Configuration实现来提供“惯例”代替配置（CoC）的方便。我最近的例子中，URL是这样“/project/123/suite/456/test/create”影射到“com.autoriginate.actions.project.suite.test.CreateAction”，然后自动的传递参数：projectId=123、suiteId=456。而Result是“[action].jsp”或者“[action]-[result].jsp”，也可以通过annotation来配置。
也就是说，WebWork是你的应用程序framework中的最佳基础工具。在这种情况以外也很好，但是目前不算最佳的“甜点”。
除去这些一般的，WebWork对于正在创建需要插件和扩展的产品的人是必备的。例如JIRA、Confluence、Jive Forums。因为WebWork支持广泛的模版语言（Velociy和FreeMarker），完整的tag支持，模块写好后非常容易插入。一个jar包就可以包括所有的action和view（得益于ftl的classpath支持）。最终的效果很好：在Confluence中你可以通过管理界面上传一个jar，这个plug-in就会自动部署。这是因为Atlassian（Confluence、Jira的小组）非常了解这个framework，并且作了很多的贡献。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
与其它action framework相同，WebWork在控制状态和wizards上比较弱。如果你写了很多长的wizards，JSF可能是比较好的解决方案。我还想说，文档还需要改善（参考文档还不错，但是教程、cookbooks和FAQ还比较差），如果没有一个WebWork高手作为项目领队，新手可能会敬而远之。
对于非常简单的程序，我推荐使用简单的JSP或者Spring MVC，如果用户接受Spring的话。但是总的来说，我认为在action framework中WebWork是最好的。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
我试验过RIFE、Spring MVC、Struts、Spring Web Flow，还有一点点Tapestry。我发现RIFE的概念很优秀，但是它的实现不怎么样。不难想象Geert还是使用“m_”作为字段的前缀。它看起来不像Java。模版难住了我，所以就没有继续看。
Spring MVC还可以，但是它是一个非常简单的framework实现。WebWork的数据绑定（WebWork世界中称为类型转换）要强多了，而且是自动的（而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%。我倒不是说这是个坏主意，但是我应该诚实的说它是一个完整的框架。
Tapestry很优雅，但是HTML属性（jwcid）惹人厌。我接受这种理念，且实践中这会带来一些好处（Shale也有相似的地方）。但是实际上，我发现“HTML/CSS开发者”和“app开发者”一般是同一个人，Tapestry就架设如此。实际上，由于Ajax的推动，我想越来越多的“程序逻辑”会被嵌入到UI；这样的话，Tapestry的模型就不那么适宜了。
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
在Struts Action 2.0我们希望：更好的文档。支持标准（如果可以，我们希望用JSTL代替OGNL，但是首先要保证不会有功能损失）。增强AJAX支持，提供更多的widgets：如自动完成。解除配置地狱；提供更多的选择，如我们开始所说的CoC。
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
他需要很多的配置：我已经演示过，通过CoC风格，它可以做的比Rails更好（Rails的管理部允许内嵌controllers）。
6、你对Ruby on Rails的看法如何？
非常重要的一点是，我要说RoR不能与大多数的framework对比，除了RIFE和Seam。对比RoR和WebWork就相当于对比Hibernate和JDBC。一个是full stack，另一个只是stack中的一部分。
另一个重要的问题：DHH是个怪胎，但是聪明的怪胎。它的高效率无可争辩，它被称为Rails。
好的，我们不说这个，随便说说别的：
我使用Rails创建了一个小的app。我把它扔掉并很快用Java重写了。我认为Rails可以让你的app中的80%快速完成；而剩下的20%比前面80%需要花的时间还多。当然程序开发就是这样。脚手架非常酷，尤其是ActiveRecord在运行时改变类。但是后来你需要写UI、自定义的验证规则，自定义安全影射等等。一个基于CRUD的app能够在30分钟内运行并不意味着你能以这个速度完成它。
Rails的web framework部分相比于WebWork很可怕。实际上根本无法比较。它的实现更接近于Spring MVC的简单功能。
完整的stack非常棒。他们在这方面做得很好，这里Java还有差距需要追赶。WebWork是web stack，但是持久化解决方案并不确定。所以最大的问题在于即使WebWork和SiteMesh提供了如配置动态读取和动态类reloading，Spring、iBatis和Hibernate并不提供。它们至少需要提供配置重读取后才可以发展出类似Rails那样的功能。类似的，Hibernate和iBatis对WebWork等的请求提供的支持不够。对于一个类，我可以不需要再xwork.xml中进行配置，但是持久化引擎并不允许我们这样做。当这些功能能够同时具备，没准一个complete stack的框架就会推出。
要求快5倍10倍是愚蠢的。可靠的工程师都知道开发产品的时候最大的警力都花费在构思代码上，而不是书写代码。定义需求，获取反馈，市场定位，定义数据库结构，映射用户接口。不管使用什么语言，你需要思考很长时间。没有语言或者框架能够提升思考的速度。
最后，Rails提供了：用脚本语言良好实现的stack。Python、Perl尤其是PHP中的其它框架还没有成熟。我认为“PHP猴子”们还有很多事情要做，他们通常不是很有才干的工程师。（可能我翻译错误了，希望纠正）。在脚本语言中提供良好的框架，人们能够实现设计精良的app并的到回报（因为脚本语言的特点）。不只是“管理代替配置CoC”甚至是集成stack，Java需要的是立刻反射出变化的能力。很多Java开源领袖认为“修改web.xml”的重新载入是一种方法。这种智力游戏应该结束了。我们不仅仅需要配置文件和类的重新载入，我们需要社区给Sun足够的压力，使其能够在下一代的JVM中提供热插拔（HotSwap）的能力。或者，更加复杂的程序模型，如OSGi，需要进一布被社区所接受。当然我并不希望走那条路线。

Wicket(Eelco Hillenius)
1、你认为你的framework的“甜点”在哪里？他最适合哪种类型的项目？
我认为有5点：Wicket是以代码为中心的：可以在view层进行OO编程。组件是完全自管理的：容易创建和重用。概念的分离是清晰的也是强迫的。干净的模版。开发伸缩性大-就像OO一样。
2、它不适合于什么样的场景？在这些场景你推荐什么fremework？它是哪个？
Wicket不适合UI很简单且只读的场合。这时页面脚本更加适合，比如JSP，或者JSF。如果你需要无限的可伸缩性，你可能需要状态无关的实现。从1.2版开始，Wicket也有无状态页面的概念，这样可伸缩性与其它framework差不多了。
3、在下面提到的framework中，你试验过他们么？如果试验过，你比较喜欢哪个？你不喜欢哪个？
JSF：
优点：基于组件。工业背景。工具支持。一些扩展让他更容易使用。它允许你从传统JSP升级到JSF。
缺点：它缺少其它API的优雅。以JSP为中心。配置很多而且代码很难看。有很多种实现。它让我回忆起EJB1/2，以厂商为中心等等。
RIFE：没用过，说了一大堆。
Seam：不是一个真正的Web framework。类似JSF扩展。如果使用EJB/JSF/JBoss组合，这个选择很好。但是不遵循JSR 227/235。
Tapestry：很好，4.0版本好了很多。我把它推荐给我所工作的公司。Wicket更加以编程为中心。而Tapestry更加pragmatic。
Trails：从来没用过。
Spring Web Flow：framework本身很好，但是我不喜欢它的stacking。如果用工作流，我希望选择一个如jBMP的方案。我也不喜欢以流为中心的解决方案，认为这样很过程化。
WebWork、Spring MVC、Struts：Model 2的framework糟透了。我用过几年，也对Maverick贡献过代码，但是我彻底失去兴趣了。Model 2 framework太过程化了，这些程序员不知道怎么用OO编程。我宁可雇佣一个Swing编程的人也不会去选择一个使用Model 2 framework编程的人，因为Swing编程的人写的程序一般更漂亮。……如果让我从这些Model 2 framework中挑一个出来，我选择Stripes，它抛弃了model 2中的一些不好的方面。
4、你的framework的未来会怎样？对于用户开发会有什么方便使用的变化？你会原生支持Ajax么？你们计划支持它了么？
我们将会支持Java5。我们会增强Spring支持，复杂的权限认证支持，和基于角色的参考实现，还会提供原生AJAX支持，URL加载（nice URLs），无状态页等。
我们的市场占有率不高，但是用户群在提高。我正在写“Wicket In Action”（Manning出版）正在筹划中，今年夏天会出版。
5、有对你们的framework的传言需要澄清么？如果有，是哪个？
关于伸缩性的问题是第一位的。程序的可伸缩型一般是由数据库性能差或者缓存策略查询优化并发等问题。服务器端可伸缩性并不一定不可扩展，可以通过集群来继绝。……
6、你对Ruby on Rails的看法如何？
我喜欢我看到的Ruby，如果我有时间我还会仔细把玩它。如果不是Wicket的问题，我希望更多的实践RoR。……

说说新添加的ww:date标签。很多朋友可能都认为ww:property输出date比较不如意，以前很多解决方案感觉都不够灵活。WW肯定察觉了，新增加的ww:date把玩了一下发现非常好用，所以推荐给大家。
语法非常简单：
name：你取值的ognl表达式
nice：是否使用易读（readable notations）的模式，其实就是类似conflunce里面显示时间的方式，类似“in 2 hours, 14 minutes”
format：就是我们常用的时间format，例如“yyyy-MM-dd hh:mm”
id：就是HTML中的元素id

使用起来如下，官方的例子：
<ww:date name="person.birthday" format="dd/MM/yyyy" />
按照“dd/MM/yyyy”格式显示
<ww:date name="person.birthday" format="%{getText('some.i18n.key')}" />
将format定义到i18n文件中的方式，这个很常用:D
<ww:date name="person.birthday" nice="true" />
使用易读（readable notations）的模式
<ww:date name="person.birthday" />
使用默认的格式输出

其中显示的规则如下：
1、如果制定了nice="true"则优先以易读（readable notations）的模式显示
2、如果nice="false"则按照指定的format显示
3、如果上面两个属性都没有指定，则从默认的资源文件中寻找webwork.date.format这个i18n的key，按照它显示
4、如果还没有找到则按照DateFormat.MEDIUM格式显示
5、特别之处：如果从ValueStack没有找到值，则默认显示空白（而不是null）

就这么简单，感觉读（readable notations）模式尤其有趣，非常好用，你还可以给它指定i18n的显示方式。
下面共享一下我写的zh_cn版本，你只需要将一下内容拷贝到classpath下面的default.properties文件中就可以了（也可以按照i18的资源文件命名规则）：

webwork.date.format.past = { 0 } 以前
webwork.date.format.future = 在 { 0 } 
webwork.date.format.seconds = 几秒钟前 
webwork.date.format.minutes = { 0 , choice , 1 #一分钟| 1 <{ 0 } 分钟} 
webwork.date.format.hours = { 0 , choice , 1 #一小时| 1 <{ 0 } 小时}{ 1 , choice , 0 #| 1 #零一分钟| 1 <零 { 1 } 分钟} 
webwork.date.format.days = { 0 , choice , 1 #一天| 1 <{ 0 } 天}{ 1 , choice , 0 #| 1 #零一小时| 1 <零 { 1 } 小时} 
webwork.date.format.years = { 0 , choice , 1 #一年| 1 <{ 0 } 年}{ 1 , choice , 0 #| 1 #零一天| 1 <零 { 1 } 天} 

输出的样子如：“一天零 8 小时 以前”，“4 天零 23 小时 以前”……

你也可以自己翻译，默认的key如下：
i18n文件默认为default.properties

webwork.date.format.past = { 0 } ago 
webwork.date.format.future = in { 0 } 
webwork.date.format.seconds = an instant 
webwork.date.format.minutes = { 0 , choice , 1 #one minute| 1 <{ 0 } minutes} 
webwork.date.format.hours = { 0 , choice , 1 #one hour| 1 <{ 0 } hours}{ 1 , choice , 0 #| 1 # ,  one minute| 1 < ,  { 1 } minutes} 
webwork.date.format.days = { 0 , choice , 1 #one day| 1 <{ 0 } days}{ 1 , choice , 0 #| 1 # ,  one hour| 1 < ,  { 1 } hours} 
webwork.date.format.years = { 0 , choice , 1 #one year| 1 <{ 0 } years}{ 1 , choice , 0 #| 1 # ,  one day| 1 < ,  { 1 } days} 

为2.2.2的Webwork发布兴奋之余也为它的未来有些担心，到Struts Action Framework发布还有挺久，其中的真空期很难等待呀，WW一向有些小毛病，靠nightly build改善还是很麻烦的。
2.2.2的更多功能的探索希望大家能够互相交流。

还有点补充：现在用ww:property输出Date类型的数据默认会显示到毫秒……请注意。

好了，语法很简单，我们说ww:action的两种主要用法。
1、代替<jsp:include>：
include有两种方式@ include和jsp:include，它们一个是编译前一个是运行时include。webwork是不能使用<jsp:include>的。
但其实ww有ww:include标签，但是根据Webwork in Action中的推荐，ww:include标签适合调用一般servlet，而对于action则推荐使用强大的ww:action。所以我们这里就略过ww:include。
说强大是什么意思呢？ww:action充当这个角色时，可以选择是否将valueStack的东西复制过来。
当ww:action代替jsp:include的时候我们需要executeResult="true"，这个时候调用的action返回的view会被include到调用的位置。<ww:action><param name="xxx" value="yyy"/></ww:action>则可以给action传递参数。其它的用法就与jsp:include或者ww:include用法差别不大了。

2、页面控制器风格Action复用：
我们经常遇到这样的场景，比如用户注册的时候需要选择单位列表。那么我们reg.action运行之前就需要先把单位列表unitsList取出来。而它们本身与User注册逻辑上没什么关系。
所以有的人把这个取出unitsList单独写在prepare()方法里面，然后用prepare Inteceptor……或者把读取unitsList的逻辑写在execute方法里面。
但是这显然难以复用！
其实如果有单位unit这样的domain，我们可能就有对应的CRUD的Action。其中可能就有UnitsListAction这样的Action。
我们完全可以在用户注册的时候就复用这个Action，而不是把同样的逻辑写到用户注册的Action里面。这就是页面控制器风格要解决的问题。
说那么多大帽子其实没有意义，我们看看怎么实现：
UnitsListAction片断（我们要复用它）：

UserRegAction假设在注册前只是doDefault()直接返回SUCCESS，只有在Post数据时在调用execute()，我们就不写空的代码了。或者不通过任何Action调用注册页面，直接调用注册的jsp文件直接访问也可以。

到了UserRegAction显示的View，我这里是Jsp片断：

<ww:action id="listUnits" executeResult="false" namespace="/" name="unitsListAction" />
<ww:select name="unitId" list="#attr.listUnits.unitsList" listKey="id" listValue="name" required="true"/>

注意，executeResult="false"，也就是说我们不渲染unitsListAction返回的view，只用它的值。
而访问它的值的时候要使用#attr.listUnits.unitsList这样的引用，因为这时unitsListAction返回的VlueStack不是页面的ognl的rootStack，我们需要访问#attr这个Stack，这部分可以参考一下Webwork的wiki。
上面我给unitsListAction规定了一个id，这样调用比较灵活，你可以多次调用同一个Action并且将值放在#attr下的不同地方。
我们引用unitsListAction返回的unitsList这个list的时候需要用#attr加上我们给unitsListAction设定的id（如果不指定id，则默认unitsListAction）再加上你要访问的变量名访问。
其实很简单，而这种方式就是开始说的页面控制器风格的action复用。虽然和真正的叶面控制器的Tapestry和JSF相差甚远，但是也算有点那个意思了。
扩展点想，如果我们在Action实现了一个counter，也可以通过这种方式调用，连返回的值都可以忽略，呵呵，这种逻辑复用还是挺有用的。

抛砖引玉，我这个人说话啰嗦，见谅，就到这里。

<action name="blahblahAction" class="blahAction" method="blah">
   <result name="success" type="redirect">/some.action?field1=${field1}&field2=${field2}</result>
</action>

运行时候出现如下提示：
The reference to entity "field2" must end with the ';' delimiter.
我本以为是OGNL的问题，四处搜寻，不得其解……看了DTD也没有发现问题。
后来修改过程中突然发现原来是SAX解析器出错，我这才想到可能是XML的问题。
经过再三查询得到解决方案：
使用"&amp;"代替"&"，原理和HTML中的转义相同，我居然忘记了XML的语法规范，惭愧。
配置如下：

<action name="blahblahAction" class="blahAction" method="blah">
   <result name="success" type="redirect">/some.action?field1=${field1}&amp;field2=${field2}</result>
</action>

工作正常了！希望对大家有用。
这几天超忙，没怎么写Blog，还是要勤呀。

但是已经是2004年11月的文章了，在webwork 2.2 b4中，XWorkList和XWorkMap已经是deprecated状态了，当时我就一头雾水，也没找到什么好的线索。
去java.net下载了XWork的最新代码，看到了其中的注释，说这个工作已经可以自动完成了。
又几经周折，才算搞明白先在如何让List、Map等工作起来，给予2.2 b4和b5工作正常：

下面简单介绍一下：
1、如果要将值映射到pojo的collection，则需要使用conversion功能。
如我又一个Action，叫testAction：

public class testAction extends ActionSupport { 
        private Collection smoeAttrs = null;//（使用webwork自动负值，应有对应getter和setter） 
        private IDeptJgzTjkEcoAttDAO ecoAttDAO = null;//（改DAO使用Spring注入，应有相应setter） 

            public String execute() throws Exception { 
                if (log.isDebugEnabled()) { 
                        log.debug("performing execute() method!"); 
                } 
                
                //持久化collection里面的pojo 
                for (Iterator iterator = smoeAttrs.iterator(); iterator.hasNext();) { 
                            SomeAttr someAttr = (SomeAttr) iterator.next(); 
                            ecoAttDAO.saveOrUpdate(someAttr, someAttr.getId()); 
                } 
                
                       return Action.SUCCESS; 
            } 
}

对应一个pojo：

package org.tin.test; 

public class SomeAttr implements Serializable { 

        /** *//** The composite primary key value. */ 
        private java.lang.Long id; 

        private java.lang.Float fild1; 
        private java.lang.String fild2; 
        private java.util.Date fild3; 

        /**//* 
                . 
                对应的getter和setter 
        */ 
}

可以看到，上面的Action声明的时候没有任何涉及到XWorkList的地方（moxie介绍的那种风格），也就是说现在webwork并不知道Collection里面放的pojo的类型。这就是Webwork目前的高明之处，这样的代码非常干净。但是如果要自动设定Collection的值，访问到这些Pojo，则一定要知道Pojo的类型，Webwork如何做呢？
通过-conversion配置。
需要在对应该才那个testAction.java的相同目录写一个testAction-conversion.properties文件（格式就是Action名字+“-conversion.properties”）。
文件里面注明：
Element_someAttrs = org.tin.test.SomeAttr （以前版本曾经用过Collection、Map分开，但是现在不管什么类型，都用Element）
格式就是“Element_”+Action中Collection的名字+“=”+你的pojo的完整类名

如此配置后，自动设置值的时候就可以知道你的pojo的类型了，很干净。

下面一小段由于我接触Webwork不久，所以是个很初级的经验，如果需要则自取：
回忆moxie帖子中的重要的部分，在post到相应action的页面的form中，input要遵循这样的命名：
对应刚才所说的那个pojo：

<form> 
        <input  name="someAttrs[0].fild1" value="45555.6" id="xxx11" /> 
        <input  name="someAttrs[0].fild2" value="test" id="xxx12" /> 
        <input  name="someAttrs[0].fild3" value="2006-01-05" id="xxx13" /> 
        <input  name="someAttrs[1].fild1" value="45555.6" id="xxx21" /> 
        <input  name="someAttrs[1].fild2" value="test" id="xxx22" /> 
        <input  name="someAttrs[1].fild3" value="2006-01-05" id="xxx23" /> 
        <input  name="someAttrs[2].fild1" value="45555.6" id="xxx31" /> 
        <input  name="someAttrs[2].fild2" value="test" id="xxx32" /> 
        <input  name="someAttrs[2].fild3" value="2006-01-05" id="xxx33" /> 
</form>

如何输出？很简单，在列表页中： 

<ww:iterator value="someAttrs" status="someAttrsIter"> 
<tr> 
        <td> 
                <ww:hidden name="someAttrs[%{#someAttrsIter.index}].id" value="%{id}"/> 
                <ww:textfield name="someAttrs[%{#someAttrsIter.index}].fild1" value="%{fild1}"/></td> 
        <td><ww:textfield name="someAttrs[%{#someAttrsIter.index}].fild2 value="%{fild2}"/></td> 
        <td><ww:textfield name="someAttrs[%{#someAttrsIter.index}].fild3" value="%{fild3}"/></td> 
</tr> 
</ww:iterator>

即可以，因为iteratror这个tag支持iteratroStatus这个东西，用它可以获取index、isOdd等信息，很方便。

配合

<action name="saveAction" class="testAction"> 
        <result name="success" type="redirect">/loadByInf.action?id=${someAttrOwner.id}</result> 
</action>

则很容易的实现对Collection的CRUD。正好用到了ONGL的集中基本访问方式：#、%{}、${}

以上内容，错漏难免。因为今天终于可以偷闲，赶紧结绳记之。欢迎大家讨论更简便的方法。