这是一篇很有趣的文档，所以摘要一下，其实类似阅读笔记，好像是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


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 ...

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 action2基于webwork2，很快会开始。现在已经支持ajax了，我们在寻找更加容易的开发方式，jsf支持（struts shale），continuation支持，还有支持更多的脚本语言（bsf扩展脚本撰写action）。

5、有对你们的framework的传言需要澄清么？如果有，是哪个？
struts太过时了，而且也不酷，难于使用。但是你可以自己修改或者扩展它。我认为团队对于你的限制远大于framework对你的限制。

6、你对ruby on rails的看法如何？
不需要d&d工具，旨在帮助开发人员提高开发效率的好例子。我们在action2中将学习它的先进理念。

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库。而tapestry4.1还要进一步强化这方面的支持。
tapestry 5.0提供了明显的改进：没有abstract类（tapestry的怪癖:）。没有强迫的继承关系。对属性进行annotation而不是方法。没有xml，只有模版和annotaions。只能类装载，自动寻找类的变化。最小化api，超越annotaion。面向方面（aspect-oriented）模块构造，使用mix-ins。

5、有对你们的framework的传言需要澄清么？如果有，是哪个？
tapestry3.0还不容易测试，4.0改善了一些。tapestry只是个人秀；实际上我们有很多活跃的贡献者。tapestry的学习曲线非场陡峭。它只有漂亮的模版实现；实际上tapestry的特点在于状态管理（允许对象存储状态，而不是多线程的单例来管理requests之间的游离和持久状态）

6、你对ruby on rails的看法如何？
很有影响力。但是模版的实现非常丑陋。我听到了很多意见，关于ror的优缺点。基于我的基本理解，这些观念对tapestry4产生了影响（它对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程序的惬意。