JAVA网页编程之Java Web 框架的“甜点”

C++编译的是本地码,优点是启动快,而且可以精确控制资源因此可以开发很高效的程序.缺点是编程麻烦,而且容易留下安全隐患.跨平台靠源代码在各个平台间分别编译(一处编写到处编译)web这是一篇很风趣的文档，以是择要一下，实在相似浏览条记，仿佛是3/25公布的：
不知怎样翻译SweetSpots，岂非翻译为甜处、长处、蜜点、蜜穴？

本文基于对以下人的采访（最初两位的意见独到仍是本人看吧！）：
JSFJacobHookom
RIFEGeertBevin
SeamGavinKing
SpringMVCRobHarrop
SpringWebFlowRobHarropandKeithDonald
StripesTimFennell
StrutsAction1DonBrown
TapestryHowardLewisShip
TrailsChrisNelson
WebWorkPatrickLightbody
WicketEelcoHillenius


JSF(JacobHookom)

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)会供应"PartialFacesRequest"，它是Ajax完成。JSF也会加强annotation组建编程。

5、有对你们的framework的传言必要廓清么？假如有，是哪一个？良多JSF书都拿Struts作为对照。他以为这不克不及表现JSF的特性。他以为Struts和WebWork能做到的JSF也能做到。

6、你对RubyonRails的意见怎样？
它与WebWork一样好用，它的CoC（ConventionoverConfigration）和脚手架十分好用。他以为CoC能够被使用在任何framework，他以为这是RoR最年夜的长处。他还以为RoR会走上别的framework的路（庞大性），由于人们必要本人的扩大。

RIFE(GeertBevin)

1、你以为你的framework的"甜点"在那里？他最合适哪一种范例的项目？
你能够支付10%的事情量，失掉别的framework的90%的......，它是一个full-stackframework（如RoR）。它吸取了成熟的分层框架的架构，并将配合的长处搜集在一同。供应了webcontinuation，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是continuationsserver
3)、RIFE从头造轮子没有供应奇怪工具
4)、RIFE的模版语法很糟糕过于复杂和专业
5)、RIFE是基于request的framework
6)、RIFE的功效太多，进修曲线峻峭

6、你对RubyonRails的意见怎样？
RoR对Java社区的打击十分棒，元编成也失掉了信托。RoR没甚么特别的地方，也没有从Ruby言语获益良多。
我厌恶：它的模版。Partials（RoR中的组件）。URL的分离处置。ActiveRecord供应了从数据库schema而来的DSL，可是却不是从domainmodel而来。没有l10n和i18n撑持。手动形态转换。不克不及在JVM运转（......）。实践上脚手架天生了实践代码。Ruby短少工具和IDE。

Seam(GavinKing)

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撑持。远程框架SeamRemotingFramework（Ajax）。模版动静的工具撑持。今后还要集成ESB，企图引擎和异步撑持。

5、有对你们的framework的传言必要廓清么？假如有，是哪一个？
这些都不是真的：JSF不克不及处置GETrequests。JSFpost后没法redirect。JSF不克不及与REST共存。

6、你对RubyonRails的意见怎样？
它是PHP的很好替换品。假如它有一个正派一点的耐久化层它就能够和Java合作了。

SpringMVC(RobHarrop)和SpringWebFlow(RobHarropandKeithDonald)

1、你以为你的framework的"甜点"在那里？他最合适哪一种范例的项目？
SpringMVC：
不乱可扩大，撑持了i18n、文件上传、非常处置，这些不乱的撑持给开辟者坚固的事情基本。是最好理论，告知你怎样做是最好的。与Spring集成，抢先的IoC远生撑持。撑持，Spring社区活泼和复杂。Struts开辟者能够光滑过渡。合适多种项目，可选的多种result范例。
SpringWebFlow：内置义务处置引擎，撑持线性处置过程当中的延续形态。笼统，削减开辟的存眷点。合适多种项目范例，插件撑持SpringMVC、Struts、JSF等。

2、它不合适于甚么样的场景？在这些场景你保举甚么fremework？它是哪一个？
SpringMVC：不合适必要组件化开辟的场景。它是一个request驱动的MVC。那些场景保举JSF或Tapestry。
SpringWebFlow：处置线性页面流，不合适一样平常的"自在扫瞄"。固然SpringWebFlow能够与request驱动大概组件驱动共存。

3、鄙人面提到的framework中，你实验过他们么？假如实验过，你对照喜好哪一个？你不喜好哪一个？
Spring框架撑持Struts和JSF集成。

4、你的framework的将来会如何？关于用户开辟会有甚么便利利用的变更？你会原生撑持Ajax么？你们企图撑持它了么？
SpringMVC：简化JSP标签。更多的MVC设置schema。CoC作风的默许把持器、URL暗射、view，进修Rails和Stripes的长处。加强数据绑定和考证（撑持范型绑定）。Portlet撑持。Spring也要承受Ajax，利用DWR库。
SpringWebFlow：一年夜堆，体贴的能够本人看......

5、有对你们的framework的传言必要廓清么？假如有，是哪一个？
SpringMVC难于设置。在Spring2.0，将会改良，可使用本人界说的基于schema的设置。

6、你对RubyonRails的意见怎样？
SpringMVC：RoR十分风趣。不外如今就拿出来用另有点稚嫩。这里举了个例子，关于变量的单数情势的处置，RoR会利用如许的CoC作风来处置变量list，而SpringMVC也实行了各种作风，可是遭到的了局却很差。人们以为英语的单数很乖僻，没有必定的划定规矩，以是会带来凌乱，如（person->people）。以是Spring...

Stripes(TimFennell)

1、你以为你的framework的“甜点”在那里？他最合适哪一种范例的项目？
与SpringMVC、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、SpringMVC。个中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、你对RubyonRails的意见怎样？
我以为Java社区有良多能够从RoR进修的中央。Stripes进修了RoR的前端部分，开辟者能够削减设置量。可是RoR的RHTML让我想到了之前的JSP中凌乱的scriptlet。尔后面的ActiveRecord是一个很好的理念，完成的也很好。ActiveRecord比Hibernate等庞大的ORM工具要简单了解，由于如许的特性RoR才引发了这么年夜的波涛。

StrutsAction1(DonBrown)

1、你以为你的framework的“甜点”在那里？他最合适哪一种范例的项目？
文档和用户基本，书本和面前的撑持。简单雇到人（也简单找事情）。固然其他项目标理念比这个要先辈，可是这些不算甚么。实践上，Web层是很简单也很间接的。

2、它不合适于甚么样的场景？在这些场景你保举甚么fremework？它是哪一个？
假如你必要portlets大概庞大的页面（显现良多工具），那末Struts要末没法事情要末太单调。这类情形你必要一个基于组件的framework，如JSF、Tapestry/Wicket。

3、鄙人面提到的framework中，你实验过他们么？假如实验过，你对照喜好哪一个？你不喜好哪一个？
这些我基础都实验过，他们每一个都事情的很不错。

4、你的framework的将来会如何？关于用户开辟会有甚么便利利用的变更？你会原生撑持Ajax么？你们企图撑持它了么？
StrutsAction2基于WebWork2，很快会入手下手。如今已撑持Ajax了，我们在寻觅加倍简单的开辟体例，JSF撑持（StrutsShale），continuation撑持，另有撑持更多的剧本言语（BSF扩大剧本撰写Action）。

5、有对你们的framework的传言必要廓清么？假如有，是哪一个？
Struts太甚时了，并且也不酷，难于利用。可是你能够本人修正大概扩大它。我以为团队关于你的限定宏大于framework对你的限定。

6、你对RubyonRails的意见怎样？
不必要D&D工具，旨在匡助开辟职员进步开辟效力的好例子。我们在Action2中将进修它的先辈理念。

Tapestry(HowardLewisShip)

1、你以为你的framework的“甜点”在那里？他最合适哪一种范例的项目？
我想Tapestry关于中等范围大概年夜范围的使用会带来良多优点（乃至你能够在单页面的使用程序中取得优点）。这里有同意你创立新的组件的优秀工具。Tapestry不体贴数据从那里来，良多“项目范例”都基于切面（aspect）（如CRUDvs.RSSfeedvs.etc.）。我以为Tapestry十分简单与IoC集成（HiveMind或与Spring），便利举行测试。

2、它不合适于甚么样的场景？在这些场景你保举甚么fremework？它是哪一个？
我在别的Javaframework中没有找到到强于Tapestry的长处。可是关于RoR，我本人没有利用过利用，很难说RoR中的项目应当是甚么模样。我没有细心对照过RIFE，它看起来受了RoR影响，特别是相似ActiveRecord的数据会见层。可是假如你的使用必要特定的URL格局，那末在Tapestry中奋克服算不年夜。

3、鄙人面提到的framework中，你实验过他们么？假如实验过，你对照喜好哪一个？你不喜好哪一个？
在这两年来我没怎样实验过Tapestry之外的工具。我没怎样进修RoR，由于工夫太无限了。

4、你的framework的将来会如何？关于用户开辟会有甚么便利利用的变更？你会原生撑持Ajax么？你们企图撑持它了么？
Tapestry4.0有很好的Ajax撑持，经由过程Tacos库。而Tapestry4.1还要进一步强化这方面的撑持。
Tapestry5.0供应了分明的改善：没有abstract类（Tapestry的怪癖:）。没有强制的承继干系。对属性举行annotation而不是办法。没有XML，只要模版和annotaions。只能类装载，主动寻觅类的变更。最小化API，超出annotaion。面向方面（Aspect-oriented）模块机关，利用mix-ins。

5、有对你们的framework的传言必要廓清么？假如有，是哪一个？
Tapestry3.0还不简单测试，4.0改良了一些。Tapestry只是团体秀；实践上我们有良多活泼的奉献者。Tapestry的进修曲线非场峻峭。它只要大度的模版完成；实践上Tapestry的特性在于形态办理（同意对象存储形态，而不是多线程的单例来办理requests之间的游离和耐久形态）

6、你对RubyonRails的意见怎样？
很有影响力。可是模版的完成十分丑恶。我听到了良多定见，关于RoR的优弱点。基于我的基础了解，这些看法对Tapestry4发生了影响（它对Tapestry5影响更深）。
RoR意味着限定了你的选择：假如你选择RoR那末就要尊旬它的理论（CoC..），看起来你的钱会花的恨值。这些相似Microsoft的哲学。而Java更崇尚给你更宽松的选择，不限制你利用的工具，可是暗昧的说这必要你对你的工具了解更深。不但对Tapestry，还关于JEE、Spring这写entirestack的框架，必要从RoR进修，不但供应工具，还必要供应整套的办理计划。

Trails(ChrisNelson)

1、你以为你的framework的“甜点”在那里？他最合适哪一种范例的项目？
Trails的使用程序只必要Web界面和耐久化的domainmodel就能够了。Trails给你的domain
model疾速的供应一个界面，除POJO本人不必要附加的代码。Trails同意你修正界面的表面和举动，包含考证、i18n、平安。这些都不必要java代码天生，不喜好代码天生的人应当感到很温馨。

2、它不合适于甚么样的场景？在这些场景你保举甚么fremework？它是哪一个？
Trails考究够用就好。它同意你疾速托付，问问你的客户：“如许够好么？”。这会改动你的事情流程，固然这不是能够掩盖一切需求的办理计划。当UI需求很高，Trails没有上风。我以为Trails合适于夹杂的使用，关于办理员他们只必要够用就好，那末就能够利用Trails。别的的部分我们能够订制开辟，我们在利用Tapestry、Hibernate、Spring来完成这些部分，Trails恰是基于它们。关于非交互的使用，Trails也不合适，如报表使用，能够思索EclipseBIRT。

3、鄙人面提到的framework中，你实验过他们么？假如实验过，你对照喜好哪一个？你不喜好哪一个？
我用Struts良多。它已经是巨大的framework。次要的缺点是它不克不及主动帮定命据到domainmodel。我也研讨过JSF，它比Struts强，可是自界说组建十分难。Tapestry十分便于自界说组建，特别关于创建高阶组件（有别的组件构成的）十分便利，Trails正在利用它。

4、你的framework的将来会如何？关于用户开辟会有甚么便利利用的变更？你会原生撑持Ajax么？你们企图撑持它了么？
关于Trails来讲我们站在伟人的肩膀上。Tapestry在ajax功效作了良多勉力，以是Trails也不难与其共舞。可是我们必要创立更多的例子来演示这些。我们也努力于让Trails简单参与到已举行的项目中。今后Trails还要到场基于实例的平安（instance-basedsecurity）（今朝正在利用基于脚色的role-based），另有methodinvocation。

5、有对你们的framework的传言必要廓清么？假如有，是哪一个？
Trails是对RoR的移植。Trails的名字来自Rails。它是基于Rails的理念，但不是对它的移植。

6、你对RubyonRails的意见怎样？
我以为我们有良多必要从RoR进修的中央，那将匡助我们享用开辟Web程序的满意。
j2EE和asp比较，其实也没什么比的，原因和我上面说那些比较差不了多少，也是稳定性，安全性，J2EE比asp高，速度上比不过asp，asp也是延续着它的拖拽控件的方法，提高速度。

是一种使用者不需花费很多时间学习的语言

Java是一种计算机编程语言，拥有跨平台、面向对java

另外编写和运行Java程序需要JDK(包括JRE)，在sun的官方网站上有下载，thinking in java第三版用的JDK版本是1.4,现在流行的版本1.5（sun称作J2SE 5.0，汗），不过听说Bruce的TIJ第四版国外已经出来了，是专门为J2SE 5.0而写的。

设计模式是高级程序员真正掌握面向对象核心思想的必修课。设计模式并不是一种具体"技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧

如果要向java web方向发展也要吧看看《Java web从入门到精通》学完再到《Struts2.0入门到精通》这样你差不多就把代码给学完了。有兴趣可以看一些设计模块和框架的包等等。

仓酷云

多重继承（以接口取代）等特性，增加了垃圾回收器功能用于回收不再被引用的对象所占据的内存空间，使得程序员不用再为内存管理而担忧。在 Java 1.5 版本中，Java 又引入了泛型编程（Generic Programming）、类型安全的枚举、不定长参数和自动装/拆箱等语言特性。

是一种由美国SUN计算机公司(Sun Microsystems, Inc.)所研究而成的语言

我大二，Java也只学了一年，觉得还是看thinking in java好，有能力的话看英文原版(中文版翻的不怎么好)，还能提高英文文档阅读能力。

有时间再研究一下MVC结构（把Model-View-Control分离开的设计思想）