Web框架主流上分为两类.doc

Web框架主流上分为两类：MVC框架和事件响应机制框架MVC框架有Struts，Webwork，Spring MVC，事件框架有JSF，Tapestry，Echo等。Java Web框架种类繁多，花样迭出，主流一点的就有Struts，Webwork，SpringMVC，JSF，Tapestry，至于非主流的就更加不计其数了。还有很多基于这些框架的衍生框架，例如基于Struts的beehive，基于JSF的JBoss Seam，基于JSF的MyFaces，Shale等等。对于开发人员来说，过多的选择是一种沉重的负担，不但需要花更多的时间去学习，也需要更多的时间去维护基于不同框架的代码。 由于面临着dotnet统一的web框架webforms以及异军突起的rails的强势挑战，Java业界也感受到竞争的丝丝寒意，这不，众多Java Web框架的核心开发人员终于可以坐到一起，商量着Web框架的统一和互操作的问题了。 /confluence/oss/display/WAG/Home 由众多Java Web框架的开发人员组成的一个团队Java Web Alignment Group，这其中包括了Struts，Webwork，JSF，Beehive，JBoss Seam，Spring MVC等众多框架核心开发人员组成，目标则是加强交流和合作，促进各个Web框架之间的协作，给Java开发人员提供尽量方便的解决方案。 他们讨论的内容在Yahoo Group：/group/java_web_alignment/ 加入这个mailist需要批准。 目前这个Group的讨论已经得到了一个显著的进步：struts，webwork和beehive的合并！ 我们知道Web框架主流上分为两类：MVC框架和事件响应机制框架。MVC框架有Struts，Webwork，Spring MVC，以及一些基于这些框架的框架，如Spring Webflow， Beehive等等；事件框架有JSF，Tapestry，Echo等。除此之外，还有一些连接两者的框架，如Struts Shale等等。 经过一段时间的讨论，Struts，Webwork和beehive三方宣布合并，共同发展下一代MVC模式的MVC框架Struts Ti。它将主要以Webwork为核心，集成Beehive的annotataion和pageflow功能，推向Struts用户群体，并且加强和JSF的集成能力。 这次合并的前景是值得期待的，在MVC领域，主流的选择将在Struts Ti和Spring MVC之间。不过从目前的情况来看，Struts Ti不会进一步和Spring MVC进行合并。Spring MVC的开发人员希望保护现有的Spring MVC合作伙伴和客户，以及在Spring webflow上面的巨大投入。 让我们期待该组织的更进一步的成果吧 Java Web 应用框架的下一个王者是谁？经过数年的“框架大战”，Java界的各种框架找到了自己应有的位置。 Spring+Hibernate+Struts已成为Java开发的主流体系。在这个体系中，Spring+Hibernate的地位应该说短期内是难以撼动了。除了新兴的Jboss Seam作为挑战者之外，几乎难有劲敌。有趣的是当初Spring、Hibernate作为挑战者，将官方的EJB成功挑落马下；这次反倒是官方的EBJ3成了挑战者，不知结局如何。 Java B/S编程中历来战火最激烈的其实还在Web层，框架的数量最多，争议最大。 一切由Struts而起，而Struts最终也坐稳了第一个时代的王座。在技术层面，Struts 1.x已经被无数人抱怨过、批评过，但终于还是稳坐王位，这充分说明了习惯的力量。“稳定压倒一切”，这句话在IT技术领域仍旧适用。 其实IT应用技术，什么新鲜玩意并不难学。难的是标准化和规范化。每个程序员都有自己的思路和习惯，写出来的代码自然是五花八门。Java何以成为编程界的老大，很重要的一点在于Java的规范化。这种规范化很高的语言适用于多人合作的大型项目，便于沟通和理解，也就便于集成和维护。Java世界为什么会框架横飞，说到底还是规范化的需要。纯JSP和Struts写Web谁快，摆明了是JSP。那撑饱了用Struts？原因在于100个人写出来的JSP，有100种写法；而100个人写出来的Struts，基本相似。Struts之成功，正缘于其在Java Web层的规范化方面所做出的贡献。 然而长江后浪推前浪，Struts 1.x的技术缺陷毕竟是隐患。 Sun力推JSF，打算一雪Web层框架缺失之耻。可惜JSF既要沿用Swing的技术路线，又要学ASP.NET，还要照顾产商的IDE，结果搞了个四不象，弄得里外不是人。当然Sun的技术实力毕竟是超强的，只要别重蹈EJB的覆辙，拿出点专断的精神（像这两年的NetBeans），做出像Swing那样水准的东西，JSF当大有作为。JSF现在比较有优势的是对Ajax的集成，这一点走在了其他框架的前面。 而Struts就更没有志气了，把WebWork换了个标签，凑出个Struts2，Bug多多。说实在话，根本不如原版的WebWork。如果不是靠了原先的fans捧场，根本就没得混。不过Struts原本就不是以技术取胜的，靠的是抢占先机带来的习惯优势。如果原先的fans们在这两年内都能转到Struts2，那么Struts二世仍将雄霸天下。 综上所述，未来两年，JSF与Struts将展开Java Web框架的最终战争。 以笔者愚见，结局有二：一是不论Struts还是JSF获胜，Java Web层都将结束混战的局面，这对Java Web开发的标准化是非常有利的，并有助于巩固Java在B/S界的地位；二是Struts1.x、Struts2、JSF三分天下，必然从整体上削弱Java在B/S界的竞争力，并将进一步被RoR、ASP.NET、PHP所蚕食。 2. Java Web开发技术的发展 在JSP盛行的头几年，业界对JSP的前景寄予厚望，这点很大方面是挟Java之威，并在Web应用开发领域体现出来一股霸气。而实际上，JSP在项目中大规模的成功应用，也接受住了考验。应该说，在JSP、ASP以及PHP的“三国争霸”较量中，JSP以强大原生语言以及丰富类库支持的优势，首先打败的是ASP，而非PHP，因为当时PHP走的是“草根”发展模式，避免了与JSP正面交峰。 JSP在大规模应用的同时，也遇到了些问题或局限，如：逻辑和页面代码容易混合在一起、调试不方便，工具支持困难等等。这些问题如何解决？ 网络的发展，是当前软件领域快速发展的一个动力！“三十年河东、三十年河西”，在Web技术发展历程中，三年都很长了。随着ASP.NET的推出，其技术上的实现是先进的，并有.NET框架的强大支持，控件事件的方式也让人觉得耳目一新。 同时，在MVC模式被业界普遍接受的形势下，JSP方面针对自身缺陷，也有所动作，如JSTL、EL等技术的引入，此外，Java Web开发技术方面的各种框架也在新形势下借助开源的力量发力，快速前进，并针对JSP所遇问题提供各种切实可行的解决方案，从而得到广泛应用。不管是对.NET阵营、还是对Java阵营而言，所有的这些发展，都提高了Web开发工作的效率和可复用性。 回首近几年来Web开发技术的发展历程，可以发现各种Web开发技术之间即是相互竞争，促进和借鉴的关系，适者生存、劣者淘汰。一个典型的例子就是曾经让很多为之倾倒的Struts，在为Java Web技术应用作出巨大贡献之后，为了进一步更好的发展，正在和WebWork走向相互的融合之路。 此外，在这竞争过程中，我们不得不提同样来自于开源社区的黑马Ruby on Rails， 在2006年，忽如一夜春风来，各种快速开发框架如千树万树梨花开。不用问，这都是被rails刺激。Groovy，Django，Able，Seam，Rife，Stripes，数不胜数。不过rails能够领先的秘诀其实是其设计思想的领先和敏捷的Web开发，一时间，到处都是新兵Ruby on Rails 挑战Web开发技术的内容，平心而论，在企业级应用方面，Ruby on Rails还有很长的路要走，在时间面前，谁又能保证永远独领风骚呢？毕竟，在开源的世界里永远不缺少奇迹！3. 开源的世界如此美好 Java Web开发技术与A有显著的不同之处，那就是开源，这相对微软技术的专有性而言，是个得天独厚的优势，因此，Java Web框架有着强大的生命力，其生命力就来源于开源社区源源不断地贡献。应该深信，开源的力量如此强大，只要开源模式成熟到一定程度，开源应用必将遍布各个领域，在Java Web开发领域里，事实也正是如此！ 王者般的Struts、轻快简洁的WebWork、功能强大而较难掌握的Tapestry、易于集成的Spring MVC，还有Java EE标准的JSF，各式各样的Java Web框架凝聚了开源社区的努力和心血，虽说都是“剑”，但此“剑”非彼“剑”，面对这么多令人眼花缭乱的“利剑”，你又如何选择？ 如此多优秀的技术摆在面前，我更愿意理解成机会！也就是给我们更多的选择机会！选择一种好的Java Web实现技术，对构架设计非常重要，我的选择原则是： l 和业务的匹配程度：选择复杂而功能强大的、还是选择简单而快速的？要根把业务的需求，进行适当选择。 l 熟悉程度。使用熟悉的技术，往往能把这种技术的潜力发挥到极致，即使是再新的技术，如果不熟悉，还是枉然。 l 技术成熟度：选择一种有口碑并经过实践验证的技术，系统的稳定型、可扩展性以及和其他技术的协作性，都很重要。 l 技术先进性：技术先进性是要考虑的，但技术先进性也是相对的，“老”技术也有其存在道理，甚至连Cobol都还没“绝迹”，所以只要在可接受范围，就不必太过计较是“老技术”还是“新技术”。 l 兴趣：这个因素应该服从上面所提到的其他因素，比如，我个人比较喜欢WebWork框架，我称之为一把好用的“妖刀”，但在实际中，我不会轻易就选择它，在大多数开发人员熟悉Struts的情况下，而Struts也适合，那就应该选择Struts。但你完全可以把你感兴趣的技术作为个人爱好来研究、学习。 把握以上原则，应该可以作出选择，一个技术是否会败落，取决的因素很多，但从另一方面来看，一种技术的生命力往往是很强的，如C，在金融、证券、电信等行业的关键业务处理中，占据了重要位置；再如Struts 1.X，虽然它的一些理念和当今新的一些框架相比，略显落后，但其已经得到相当规模的应用，就是在Struts 2面前，它在应用中的地位也不容忽略。 开源模式加速了技术发展，技术发展让我们不断进步，就Java Web开发技术来说，做好选择是必然，深入掌握好一种技术，再尝试其他类似技术，大多情况下，可以做到触类旁通。 可以说，随着SUN一系列Java开源策略的出台，开源社区在包括Java Web技术在内的Java诸多技术领域里的贡献将变得越来越多，影响力也会越来越大，Java也将在开源力量的帮助下，进一步巩固其在企业级应用开发领域的霸主地位。 4. Java Web开发趋势 未来Java Web开发技术的发展趋势仍然是多元化发展。其中的任何一种技术，都有其优、缺点，如Tapestry是一种组件式框架，功能强大，但学习曲线陡；JSF也是一种组件式框架，而且又是Java EE的标准之一，但仍不够成熟。在Java Web开发领域，“理性分析，合理运用” - 这是正道。 纵观2006，Java Web开发技术的发展脚步一刻也没减缓：Java EE 5正式发布（JSF版本为1.2，JSP版本为2.1）；Tapestry 4.0正式发布；Spring 2正式发布；Struts 2正在努力打造中，并发布了2.0.1 BETA版。就我自己的看法，2006年Java界最重要的事件绝对是Java开源！其意义必重大、影响定深远！随着Java开源，开源社区已是“就等东风来”，有关Java的各种技术和应用，在增添了开源的魔棒的挥舞间，终会是精彩纷呈。 期待2007，Java Web开源世界美好依旧！并完全有理由相信会继续得以发展。作为Java Web开发者，以下几点是值得你注意的： AJAX支持将更成熟：在Web 2.0浪潮里，谁也不能忽视AJAX技术，Windows Vista携带dotnet3.0 framework就要发布了，仿佛Microsoft要改变浏览器统治桌面历史的序幕就要拉开了。但是我的预测却是AJAX不但是一种过渡技术，也将成为长期存在的技术。XAML无法改变互联网HTML的实质超联接，就无法改变浏览器统治桌面的局面。 EJB3.0规范正式推出：在五月的JavaOne，EJB3.0规范正式推出。到年底之前完整通过EJB3.0认证的Hibernate3.2已经推出，包括Spring2.0提供的标准JPA支持，EJB3.0已经不存在技术上的推广障碍。但是似乎姗姗来迟了些. 各种Java Web框架继续推陈出新：喜欢新鲜事物的开发者，特别是Struts开发者，好好留意下Struts 2。 SOA：在2006年有一个现象，“咸与SOA”，每个人都会去讨论一下SOA，搞构件的普元也开始SOA了，SOA是一个2006年彻底被用烂的词汇，而真正的SOA大家还都没有接触到。 Java开源后的影响：到底会有哪些影响和变化？现在还不得而知，只能让时间来告诉我们了。 Java SE 6：Java SE 6在2006年末正式发布，我始终觉得Java SE 5的发布比版本6来得更有意义，但不管怎样，好好研究Java SE 6的新特性，是应该的。 简化开发：Java Web开发技术的功能越来越强大，使用越来越复杂，学习曲线越来越陡，在2007年里，谁能在功能强大和简化开发两者间实现最佳平衡方式？至少对于我来说，值得关注。 开源：总之，开源，还是开源！ “两岸猿声啼不住，轻舟已过万重山”，Java Web开发技术在开源动力的牵引下，过的“山”已是不计其数。 乘着开源轻舟，继续远航。 “简单就是美”空想（响）曲 在软件设计领域中，有一句脍炙人口的至理名言简单即美好。几乎所有的软件设计大师，都会在其著作中训导读者：“简单即美好”，“Keep it simple, Stupid”，“Less is more”，. 这是一条耳闻能详，人人都会说的至理名言。但实际上，这也是一条被违背得最广泛、最彻底的至理名言。“简单就是美”这个真理就好像天堂一样，人人都说天堂美好，但人人都拼命拖延到达天堂的时间。从总体趋势来讲，软件开发技术总是变得越来越复杂，越来越庞大。我们来看Java Web表现层技术的发展历史。（1）首先，Servlet诞生了。Web程序员们很高兴，觉得用起来比CGI爽多了。（2）过了一段时间，人们就觉得在Java程序里面写HTML太不爽了。毕竟，在HTML中，静态的文本标签占大部分，动态显示部分只是小部分。不如在HTML里面写Java代码。于是，JSP诞生了。成为了ASP的一个有力竞争对手。（3）过了一段时间，人们又觉得HTML和Java代码混杂在一起，不仅页面结构很差，而且其中的Java代码也很难维护。这就是著名的“Java Code Pollution”问题。不如用自定义的XML元素替换Java代码，这样，整个页面就XML化了。于是，TagLib就出现了。（4）可还是有一个问题，TagLib不能在一般的HTML浏览器或编辑器里面显示，页面不能所见即所得。而ASP.net挟Visual Studio快速可视开发之优势，正在Web开发领域攻城掠地。Java世界仓促应战，启动JSF项目。成员众多的Web Framework阵营中又多出一位权威的重量级选手。各种新概念层出不穷，页面流程越来越复杂。据说这是为了降低开发难度，让程序员只关注于业务逻辑，而不用关心底层的技术细节；据说这是为了企业级应用，而企业级应用的需求是复杂的，所以，把简单问题复杂化是有道理的据说，这是为了系统的面向未来的可扩展性、可伸缩性.这是个神话广为流传的年代，这是个概念批量制造的年代。深度思索一番，我想，技术的复杂化趋势，也许是技术市场的商业内需所致？新技术出现的驱动力一般有两种：（1）第一种驱动力是为了解决真正的问题。比如，Servlet的出现，是为了解决CGI的空间时间消耗问题。较CGI而言，Servlet是一种新思路，一种替代技术。第一种驱动力来带来的新技术的产生周期比较长，不足以维持人们对技术的需求。（2）第二种驱动力是为了弥补前一个技术的不足。复杂的技术总有一些不足之处，于是为下一次技术革新创造了内需。而且，技术越复杂，不足之处就越多，技术“创新”（或者叫“修补”更合适？）的内需和商机就越大，形成一条自产自销的技术“修补”产业链。比如，JSP的出现是为了辅助生成Servlet；而TagLib的出现则是为了弥补JSP的不足；TagLib可视化插件则是为了弥补TagLib的不足。商机无限，涌现出一大批提供各种TagLib及TagLib可视插件的技术厂商，技术市场一片繁荣。这第二种驱动力带来的新技术的产生周期比较短，而且子子孙孙无穷匮也，绝无断炊之虞。但我坚信，技术总有一天要返朴归真。总有一天，我们会回到真正解决问题的道路上来，而不是继续一条技术“修修补补”之路。2fastm的诞生“简单就是美”王者归来Java世界是一个开放的世界。我想，正是因为这一点，广大的Java程序员才舍不得离开这个Java开发阵营。公布了所有的java技术规范。开源社区吸引了大量的程序员加入Java开发阵营。为更广大的程序员（不仅是Java）提供了交流、共享和发展的空间。正是因为这样的开放性，促进了Java开发技术的空前发展。也正是因为这样的开放性，形成了Java Web表现层技术群雄逐鹿的局面。在Java Web表现层技术领域，JSP+TagLib页面技术是权威，是规范，但这个领域也不排斥其它的技术。如上所述，JSP+TagLib并不是完美的技术，所以具有不断改进发展的内在需求。同时，这一点也促使人们不断探索、比较其它的技术可能性。 Web表现层之下的所有层次O/R层、业务层、Web Framework等都直接由Java代码实现，都能够很好的结构化，对象化，不存在任何问题。唯独Web表现层，天生结构松散，野性难驯。我是一个Java Webapp程序员，一直执著地努力把Web表现层做得具有同样的结构化，对象化。两三年来，我应用、研究、比较了多种Web表现层技术：（1）Velocity /velocity/ (and WebMacro, FreeMarker. etc)（2）Tapestry /tapestry/（3）Echo /projects/echo（4）Cocoon (XML + XSLT) /（5）XMLC（Static DOM） /（6）NekoHTML (Dynamic DOM) /andyc/neko/doc/html/（7）JDynamiTe（PHP Template Port）/projects/jdynamite通过研究比较，我发现了模板技术中的“万恶之源”模板里包含的逻辑代码（if, else, for, 赋值, 操作, 调用等）。这些包含在模板里的逻辑代码，是“所见即所得”开发的天敌，也是毁坏重用性的罪魁祸首。JSP + TagLib，Velocity，Tapestry，XSLT等都是含有逻辑的模板。如果没有特殊的插件，这些模板都无法正确在普通的HTML浏览器或编辑器正确显示。而且，混杂在HTML中的逻辑是没有办法重用的；你无法把这些逻辑分离出来为通用的方法或类。JDynamiTe是一个把PHP模板技术移植到Java的一个开源项目。JDynamiTe模板用注释（BEGIN-END）标记动态块，用标记占位变量。JDynamiTe模板不包含任何逻辑，是“所见即所得”的模板技术，能够在普通的HTML浏览器或编辑器正确显示。XMLC等DOM模板技术直接使用HTML文件作为模板，当然也是“所见即所得”的模板技术。JDynamiTe和XMLC的共同点是，模板中不含有任何逻辑，所有的模板处理逻辑（检查判断、节点拼装、变量替换等）全在代码中完成。这两种技术虽然把逻辑从模板定义中分离了出去，但用法上却没有把逻辑和数据从模板中彻底地分离出去。我们来看XMLC技术中的HTML DOM的用法。一份HTML DOM刚生成的时候，还是一个纯洁的模板。但随后，程序就直接改动HTML DOM的节点数据，甚至改变节点的位置和数量，这份HTML DOM再也不能当作一个纯洁的模板重用了，更别说在多线程的环境中被多个线程同时使用了。想想看，在一个静态文本占绝大部分的DOM结构里，这种做法将造成多么大的空间和时间上的浪费。JDynamiTe的用法具有和XMLC同样的性能问题。我冥思苦想如何解决这种性能上的缺陷，最后，在JDynamiTe、PHP、DOM的思路的基础上，我创造了Template DOM和ValueSet DOM的概念，从用法上，进一步把数据和逻辑从模板中彻底地分离出去。于是，fastm开源项目诞生了。3小、快、简、易、强的“银弹” fastmfastm具有其它页面生成技术不可比拟的优越性：所见即所得，易学易用，开发速度快，运行空间小，运行速度快，模板与数据的彻底分离，模板与数据的多对多自由匹配。fastm从各方面来说，是最好的模板技术最快，最小，最易用，最灵活强大（和纯Servlet/JSP一样灵活强大）。我期望fastm这种页面生成方式，能够较好地解决Web页面生成问题，能够在全世界的Java Web程序员中流行起来。 上面这段话是否只是不自量力的自卖自夸？这点很容易辨别：fastm是完全开放的一个开源项目，一试便知。由于fastm的思路、实现和用法简单易懂，这一试也花不了什么时间。 fastm真正地证明了“简单即美好”。下面我具体讲解一下fastm的思路和用法。3.1 fastm模板是轻量级的DOM 和PHP模板一样，fastm模板只包含三种元素：（1）静态文本。（2）占位变量。用标志。（3）动态块。用BEGIN-END DYNAMIC标志。 其中，动态块可以包含其它的元素子动态块，占位变量，静态文本。所以，fastm模板是一个树型结构，相当于一个轻量级的DOM结构。后面我们就称这个结构为Template DOM。 下面举个简单的例子。比如下面的HTML片断。code /code 这个片断包含一个BEGIN-END块（zipcodes），这个块里包含两个相同的变量，其它的部分都是静态文本。 这个片断的fastm Template DOM结构如下： code静态文本 动态块zipcodes - | - 静态文本 | - 变量 | -静态文本 静态文本 /code 看起来，fastm的Template DOM也没有什么特殊的。但Template DOM具有一个至关重要的特性只读，不可改变。既然只读，那么当然线程安全，同一份Template DOM能够同时被多个线程并发使用。 那么我们如何从只读的Template DOM得到动态页面呢？我们必须把动态数据装载到一个ValueSet DOM结构（也是一个树型结构）中，然后用这个ValueSet DOM匹配Template DOM，生成动态结果。3.2 Template DOM + ValueSet DOM = Dynamic ResultTemplate DOM包含三种元素节点：静态文本节点、变量赋值节点、动态块节点。由于静态文本节点不需要赋值，ValueSet DOM只包含两种元素节点变量赋值节点，和动态块赋值节点。其中，动态块赋值节点可以包含子动态块赋值节点和变量赋值节点。所以，ValueSet DOM是和Template DOM动态部分对应的一个树型结构。 Template DOM和ValueSet DOM之间的节点对应关系如下：Template DOM的变量节点和ValueSet DOM的变量赋值节点之间是一对一的关系。而Template DOM的动态块节点和ValueSet DOM的动态块赋值节点之间是一对多的关系，这是为了让动态块能够在页面中多次显示。 我们来为上面的Template DOM结构（zipcode Select）构造一个ValueSet DOM。 String zipcodes = “361005”, “100008”; IValueSet top = new ValueSet(); / 对应上面的整个HTML片断List items = new ArrayList(); / 对应 动态部分zipcodesfor(int i = 0; i zipcodes.length; i+) IValueSet item = new ValueSet(); item.setVariable(“”, zipcodesi); items.add(item); top.setDynamicValueSets(“zipcodes”, items); 我们把top这个ValueSet DOM和Template DOM结合起来。就生成如下结果。 code 361005 100008/code 一份Template DOM可以匹配多个ValueSet DOM。同样，一个ValueSet DOM也可以匹配Template DOM，把相同的数据显示在不同风格的模板中。 比如，我们还有这样一个HTML片断：code /code 我们把上面的top ValueSet赋给这个模板。得到的结果如下。code 361005 100008/code 我们可以看到，Template DOM就是模板，只包含显示风格和分块定义。ValueSet DOM就是数据，只包含数据。 ValueSet DOM和Template DOM的分开，是一个极大的思路上的创新和飞跃。毕竟，页面中的动态部分，和静态比起来，是非常小的一部分。ValueSet DOM代表动态部分，由程序随时生成，可以存在多份。Template DOM代表静态部分，只需要解析一次，而且只需要一份。 ValueSet DOM和Template DOM的分开，更是一种前所未有的彻底的显示和数据的分离。比XML/XSLT的方法更加彻底。XML确实是纯粹的数据，但XSLT中却不可避免的要包含逻辑。ValueSet DOM是纯粹的数据，没有任何逻辑，Template DOM是纯粹的显示模板，也没有任何逻辑。 由于数据结构是DOM结构， fastm实现Tile，Portal等功能，可以说是Super Easy。你绝没有必要把页面组装逻辑别别扭扭地写在一堆复杂的TagLib里面，你可以大大方方地把页面组装逻辑写在一个很小的公用方法里面。 3.3 fastm资源列表/projects/fastm用户可以从这个地址下载fastm和fastmweb的源代码文件、使用文档。其中的fastmweb是fastm的辅助项目fastmweb，帮助定义装载Web环境中的fastm模板。同Velocity一样，用户可以在任何web framework中使用fastm模板技术。 /projects/lightweblightweb是fastm作者开发的一个轻量级的Web Framework。其演示程序demo-fastlight演示了如何在lightweb框架中使用fastm，并和jsp程序进行了比较。下载解开之后，可以直接在Web Server（如Tomcat）中运行。4技术展望 挽救B/S Webapp？我确信，fastm一定会作为一种模板开发标准流行起来。当然，其间必定会遭遇习惯和成见的巨大阻力，毕竟，fastm的作者只是一个名不见经传的无名之辈。但fastm终会胜出，只是时间早晚而已。一旦fastm的知名度超过某个阀值，fastm必将以星火燎原之势攻城掠地，争夺所有“复杂”模板技术的用户。 短期来看，fastm消灭了复杂，就等于消灭了大量的商机。fastm本身又如此简单，提供不了足够的新的商机；技术作家连写fastm in Action的机会都没有，因为fastm的定义和用法都太简单了；而且fastm极大地降低了Java Webapp的技术门槛，是否会令Java Web程序员贬值？fastm对 Java 开发阵营有什么好处？ 长期来看，fastm能够帮助Java开发阵营夺回ASP.net在Web开发领域夺走的领地，改变两大阵营的力量对比。fastm足以与Visual S（ASP）相较，甚至更胜一筹。fastm模板不需要任何特殊的支持，就能够在普通浏览器中“所见即所得”；ASP模板必须在Visual S中才能正确显示（而且是以form的形式显示）。fastm模板比ASP模板简单多了。从用法来说，甚至比其源头PHP模板还要简单。使用fastm，大量的PHP程序员可以直接转到Java Web开发阵营，而不用学习那些庞杂复杂的新模板技术。JSR-223是一个Java与PHP等脚本语言（还有Perl，Python，Ruby，Tcl）等互操作的JSR。/en/jsr/detail?id=223 目前正处于初稿审定阶段。这从另一个方面说明，fastm生逢其时，直接为Java和PHP程序员提供Java Native的PHP改进模板。至于fastm是否会令Java Web程序员贬值。我想，可能会让某些复杂技术的专精高手（比如JSP调试高手，各种TagLib使用高手）贬值。但fastm不会令解决真正问题的高手贬值，相反，fastm会帮助这些高手把精力更集中在解决真正的问题上。 关于目前如火如荼的JSF，我很高兴看到这个功能强大的开发框架的出现。但说实话，我不认为，TagLib可视化拖放开发足以和Visual S（ASP）竞争。那等于以己之短，较人之长。而且，一个潜在的危险是，Java Web开发框架将被引上一条微软倡导的“C/S结构、桌面客户端”的不归之路。 目前的一个趋势是，B/S开发框架尽量向C/S开发框架靠拢。几乎所有的现代Web开发框架都在努力地追求着基于事件机制的处理方式把前台页面组件和后台处理代码绑定在一起。Visual S的ASP开发工具是一个典型的类C/S的B/S开发结构。JSF的Webapp开发工具部分也亦步亦趋，跟着走上了这条路。不仅在服务端的开发框架存在这种趋势，在客户端这种趋势也愈演愈烈。继ActiveX，Applet之后， XMLHTTP，FLEX等新一代的“浏览器插件客户端技术”方兴未艾。开源社区Mozilla提出并支持XUL技术。微软的LongHorn 64位操作系统提出“桌面即浏览器”（其实等于宣告浏览器的消亡），力推XAML。HTML不被双方看好。HTML前景堪忧。一种可能性：将来HTML很可能只作为一种历史资料的记录格式而存在，而不会作为应用程序的UI存在；而HTML浏览器也只将作为一种历史资料查看器而存在；HTML B/S Webapp时代结束。 可以说， B/S Webapp正是毁于自身越来越复杂的内需和开发结构。B/S Webapp的界面的互操作性要求越来越强，浏览器需要支持的特性越来越多，附带的插件也越来越多（Java Script，ActiveX，Flash，XUL）。既然这样，为什么还用浏览器？Web Service协议比HTTP协议格式更完善，直接用Web Service客户端不是更直接，更彻底？微软把握并引导这个趋势，Java世界也做好了两手准备。无论是Visual S，还是JSF，其重头戏都是支持Web Service应用程序开发。毕竟，Web Service是属于未来两年的技术。 Web将变得越来越来越强大，无处不在。Semantic Web更有效地把整个Web资源组织为一个巨大的文档库、数据库、资料库和服务库。在这个大好形势下，主角将是各种Web Service Agent，而现在正当红的主角HTML B/S Webapp却面临着将来（几年）出局的可能。（呵呵，先别急着说这是危言耸听，我只是假设这样的可能性） 倾巢之下，岂有完卵？如果HTML B/S Webapp消亡了。大量的HTML TagLib就随之淘汰了。Tapestry，XMLC，Echo也随之淘汰了。XML + XSLT的项目也许还能够幸存比如，改造XSL，输出XUL或XAML。fastm当然也会幸存fastm也能够“所见即所得”地生成XUL和XAML。只要有动态生成可视化XML UI的需求，fastm就有用武之地。 如果B/S Webapp注定要退出历史舞台，fastm也无力挽救，但fastm至少可以拖延这个过程。fastm极低的技术门槛能够吸引大量的页面开发人员，留连在HTML B/S Webapp的领域里。而且，fastm既属于现在，又属于未来。既可以用作构建现在的HTML、WML UI，也可以用于构建将来的XUL、XAML UI。1.可以论证的是,就我们的简单视图来说,它的XSLT格式表比我们迄今为止所见过的那些方法更复杂,更难理解.尽管在掌握了XSLT的情况下该格式表是简单的.证明使用XSLT作为示例应用的视图技术正是示例应用的业务需求所要求的将是一件困难的事情.2.XSLT和XPATH最好是在数据已经以XML形式存在的时候使用,但如本节的示例中所显示的,把JAVA组件模型转换到XML也是相当容易的.3. 那么 Velocity 到底是什么呢？它的官方解释是：Velocity 是一种基于 java 的模板引擎，它允许任何人使用简单而强大的模板语言来引用定义在 java 代码中的对象 你可能因为下面几种原因而使用 Velocity:1:它很容易集成在各种各样的程序领域中。2:它为网页制作人员提供了一种清晰而又简单的语法3:因为模板和代码是分离的，所以你可以分别独立的开发和维护它们。4:Velocity 引擎可以很容易的集成到一些 Java 运行环境，特别是 Servlet.5:Velocity 使得模板可以访问任何环境对象中的共有方法。 Velocity 的强大之处在于它严格的区分程序开发功能的职责划分。 它限制模板可能访问的对象（也就是后台程序允许它得到的对象）来实现这一点。这意味着，网页设计人员可以只把精力放在数据的显示部分（View 视图）而程序员则只要关注如何写好程序的控制层（Controller,控制器）和商业逻辑和数据管理（模型 Model）, 这就是 MVC 开发模式。MVC 现在已经是广泛接受的一种开发模式，它简化了开发和日益复杂的应用和维护工作。 Velocity 最擅长做哪些方面的工作呢？1： 基于 servlet 的网站制作2： Java 和 Sql 代码生成3： XML 处理和转换4： 文字处理，比如生成 TRF 文件。 不过 Velocity 用的最多的还是在基于 Java servlet 的网页程序中作生成网页的引擎，以替代 JSP 等技术。 除了比较容易使用外， 它提供了强大的模板语言以显示和操作数据，但是不是生成数据，这点很重要， 因为这个工作应该是程序逻辑的部分。 Velocity 非常适合在 J2EE (Java 2 Platform, Enterprise Edition) 的网站开发中充当替代 jsp 做输出页面的技术工作，虽然 JSP 包含在 j2ee 的规范中，其实 j2ee 本身并不需要 jsp . Velocity 是如何工作的呢？ 虽然大多 Velocity 的应用都是基于 Servlet 的网页制作。但是为了说明 Velocity 的使用，我决定采用更通用的 Java application 来说明它的工作原理。 似乎所有语言教学的开头都是采用 HelloWorld 来作为第一个程序的示例。这里也不例外。 任何 Velocity 的应用都包括两个方面:第一是： 模板制作，在我们这个例子中就是 hellosite.vm:它的内容如下（虽然不是以 HTML 为主，但是这很容易改成一个 html 的页面）Hello $name! Welcome to $site world!第二是 Java 程序部分：下面是 Java 代码import java.io.StringWriter;import org.apache.velocity.app.VelocityEngine;import org.apache.velocity.Template;import org.apache.velocity.VelocityContext;public class HelloWorldpublic static void main( String args )throws Exception/* first, get and initialize an engine */VelocityEngine ve = new VelocityEngine();ve.init();/* next, get the Template */Template t = ve.getTemplate( hellosite.vm );/* create a context and add data */VelocityContext context = new VelocityContex