Web页面技术综述（包括fastm）
1. 序
Java Web Application中，页面生成部分是最繁琐、令人头痛的部分。
其它的层都可以很好的结构化，唯有页面生成部分的结构很散乱。
本文首先介绍并比较各种页面生成技术，然后具体介绍作者的一个把PHP 模板改进到Java的开源项目——fastm。
我希望fastm能够帮助广大Java Web程序员从繁琐的页面开发工作中解脱出来。
2．页面生成技术综述
本文所指的页面是XML，HTML，WML等能在浏览器中显示的Web页面。
按照页面处理逻辑的位置划分，页面生成技术可以分为两大类：
（1）一类是，页面本身包含逻辑（if, for, etc）。比如，JSP + TagLib, Velocity, XML + XSLT（处理逻辑在XSL文件中），Tapestry等。
这一类技术中，由于页面本身包含逻辑，页面组件的结构和可重用性都不是很好，无法使用“对象” 、“类”、“包”等面向对象的特性。
（2）另一类是，页面本身不包含逻辑。比如Echo，XMLC，DOM + XPath，Echo，PHP，JDynamicTe, fastm等。
这一类技术中，由于处理逻辑在Java Code里面，所以，Java程序的结构和可重用性能有多好，页面组件的结构和可重用性就能有多好。
下面分别讲解和比较这些页面生成技术：
2.1．JSP + TagLib
JSP + TagLib 是Sun公司的页面生成技术规范。
优点：
权威，规范，使用者众多，第三方提供了大量的TagLib支持。
而且，JSP本质上是Servlet。其中的Java Code部分非常强大而且灵活，能够达到Java语言最大的灵活度。
TagLib能够达到一定程度上的页面元素重用。TagLib还能够在一定程度上，帮助驱逐JSP页面的Java Code“污染”部分。J
缺点：
JSP的缺点很明显。Java Code和HTML页面内容混杂在一起，这是让广大程序员最头疼的Java Code Pollution问题。即使用TagLib也不能完全解决这个问题。
而且，程序员和页面编辑人员无法在同一个文件上工作。每次页面编辑人员编好了HTML页面，程序员必须重新加入Java Code和TagLib。
而HTML页面一旦加入了Java Code和TagLib，就无法在页面编辑器（Dream Weaver, Front Page）中正确显示了。程序不跑起来，就无法看到JSP页面的页面结构、显示风格和内容。
关于效率，灵活性，结构性，可重用性，JSP + TagLib是一个两难的选择。
在JSP中大量的使用TagLib，能够使得JSP的页面结构良好，更符合XML格式，而且能够重用一些页面元素。但TagLib的编译之后的代码庞大而杂乱，而且运行效率很低，严重影响响应速度。TabLib很不灵活，能完成的事情很有限。TabLib代码本身的可重用性受到TagSupport定义的限制，不是很好。TagLib的编写不是一件愉快的事情。J
如果在JSP中大量使用Java Code，那么页面的结构性会很差，难以管理。所有的代码都在同一个文件中，遇到大的HTML页面，简直如同噩梦一般。从一个左括号“{”找到对应的右括号“}”都变成很痛苦的一件事情。镶嵌在Java Code中间的HTML元素的是无法重用的。所以，除了Include file或者jsp:include，JSP中的Java Code根本就没有可重用性。
2.2．Velocity
http://jakarta.apache.org/velocity/
Velocity是一种模板处理工具。Velocity模板由HTML中夹杂一些Velocity脚本语言或变量定义组成。
优点：
Velocity的脚本语言（以#开始）或变量定义（用$标志）和HTML、WML、XML等的元素定义不冲突。
简单的Velocity页面（不包含分支和循环逻辑）能够在页面编辑器（Dream Weaver, Front Page）中正确显示。
缺点：
同样，Velocity模板的页面处理逻辑和HTML元素混杂在一起。如果Velocity页面的逻辑复杂的话（比如有循环和判断分支），那么该Velocity页面同样不能在页面编辑器（Dream Weaver, Front Page）中正确显示。
遇到大的HTML页面，从一个 “#if”找到对应的 “#end”也是很痛苦的一件事情。镶嵌在Velocity脚本语言中间的HTML元素的是无法重用的。所以，Velocity模板中的脚本代码和HTML元素也不具有可重用性（include file除外）。
2.3．XML + XSLT
http://cocoon.apache.org/
Cocoon项目采用XML + XSLT的方法。Java程序只需要输出XML数据，Cocoon框架调用XSL文件把XML数据转换成HTML、WML等文件。
优点：
程序员省事了，不用考虑页面结构和显示方式，只需要输出XML数据即可。
同一份XML数据，只要定义不同的XSL文件，就能够很方便地产生不同显示风格的页面。
在内容和显示风格分离的方面，XML + XSLT这种方法做得最好。
缺点：
慢。XSLT的速度比较慢。
由于没有HTML文件，根本看不到页面结构、显示风格和内容。只有程序跑起来，XSLT转换之后，才能
XSL语法比较难以掌握，由于没有“所见即所得”编辑工具，学习成本较高，远远高于HTML的学习成本。
2.4. Tapestry
http://jakarta.apache.org/tapestry/
Tapestry扩展了HTML元素的定义。Tapestry用这些扩展的HTML元素属性来表示处理逻辑（循环，分支等）、组件定义和变量定义。
优点：
整个Tapestry页面文件都是HTML元素，能够在页面编辑器（Dream Weaver, Front Page）中显示。但显示的样子是否正确，是另一回事，和包含的处理逻辑（循环，分支等）的复杂度相关。大致和Velocity的情况相似。
Tapestry的页面组件重用性比较高。
缺点：
复杂。Tapestry的定义和用法都很复杂。由于复杂，所以慢。
我没有实际使用Tapestry的具体经验，这里就不继续妄加评论了。J
2.5. XMLC
http://xmlc.enhydra.org/
XMLC把HTML、WML等文件编译成一个DOM结构的Java类。程序员不用管页面，只需要操作这个DOM结构，就可以动态生成页面。
XMLC根据HTML元素的id定义，生成相应结点的操作方法。
优点：
页面是纯粹的HTML，没有任何逻辑。能够在页面编辑器（Dream Weaver, Front Page）中正确显示。
Java Code处理DOM结构，代码结构和可重用性良好。DOM节点即HTML元素，即页面组件，也具有很好的可重用性，你随时可以把一个DOM节点放到任何文档中的任何位置。
由于是静态编译，没有动态解析过程，文档生成的速度很快。
缺点：
每次修改HTML页面，必须重新把HTML文件编译成Java文件。而且，很多HTML都不是良好的XML结构，不能够正确地编译成DOM结构。
该DOM结构不能在多线程环境中重复使用，这就意味着，每一个页面请求，都需要生成一个单独的DOM结构，占用内存空间比较大。而且，每个DOM结构使用过之后，也很难清空重置，很难提供给下一个请求使用。在HTML文件比较大的时候，内存的开销显著增大。
XMLC有些方面不够灵活。比如，我们知道，很多Java Script方法定义在XML注释当中。比如：
如果Java Script中有需要动态生成的部分，而注释部分的Java Script不是XML结构，XMLC很难处理这种情况。
2.6．DOM + XPath
前面讲了XMLC把HTML静态编译成DOM结构。
我们也可以采用动态生成DOM结构的方法，然后用XPath定位DOM结点并操作它们。
NekoHTML（http://www.apache.org/~andyc/neko/doc/html/）是一个HTML文档解析工具。
NekoHTML使用Apache Xerces（http://xml.apache.org/xerces2-j/index.html）的Xerces Native Interface对HTML文档进行解析，能够自动补足并修正不符合XML文法的HTML元素，并生成HTML DOM文档树。
Apache Xcerse的XPathAPI，可以用XPath方便地定位DOM结构的结点。DOM + XPath的详细用法请参见NekoHTML的使用文档。
优点：
大致具有上述XMLC方法的优点。
没有静态编译过程，动态生成DOM结构，及时反映页面文件的变化。
缺点：
大致具有上述XMLC方法的缺点。
DOM结构的动态生成比较花时间。我们可以采用这样的方法解决这个问题，把第一个生成的DOM结构作为标准模板。我们不对标准模板操作，每次请求需要一个DOM结构的时候，我们就从这个标准模板深度拷贝（deep copy）一个新的DOM结构，然后使用这个新的DOM结构。这样每个HTML文件只需要解析一次，成为标准模板。每次HTML文件更改的时候（这种情况很少），标准模板也跟着更新。
XPath的解析和定位速度不是很快，几乎每次都要遍历整个文档树。
2.7．Echo
http://sourceforge.net/projects/echo
Echo项目中不用定义模板文件。程序员按照Swing的方式写代码，Echo帮助你生成HTML结果。
优点：不用处理HTML部分。Swing是可重用性极好的真正组件。
缺点：Echo把HTML屏蔽起来，自动生成了很多JavaScript和HTML代码。对于Web程序来说，不够灵活，难以维护。
2.8. PHP
PHP模板的设计思路很好，PHP模板用XML的Comment注释部分来定义动态结构，用{}来标志需要替换的变量部分。
优点：
页面编辑器（Dream Weaver, Front Page）不显示XML的Comment注释部分，而且{}符号和XML元素定义不冲突。所以，PHP模板本身符合HTML语法，能在页面编辑器（Dream Weaver, Front Page）中正确显示。程序员和页面编辑人员可以在同一份页面文件上工作，所见即所得。
简单，易用，灵活（几乎和最灵活的JSP Java Code一样灵活）。具体用法见后面。本文的主要目的就是介绍PHP模板及其Java Port的用法。J
缺点：
比起其它的页面技术来说，这种技术的缺点很少。
一个需要提到的地方，也是Java Script方法定义在XML注释当中的情况。比如：
因为PHP Template采用XML Comment来定义动态结构，所以我们不能在Java Script中定义结构。但我们不需要在XML Comment中定义动态结构，我们可以用{}标志需要动态改变的地方，完全能够达到同样的目的。
2.9 JDynamiTe
https://sourceforge.net/projects/jdynamite
从各方面来说，我认为PHP是最好的页面生成技术。
我的一个同事向我介绍了PHP Template的定义和用法，我产生了浓厚的兴趣，并产生了把PHP Template移植到Java的想法。我首先到网上搜索了一下，发现了JDynamiTe (Java Dynamic Template) （https://sourceforge.net/projects/jdynamite）开源项目。JDynamiTe能够把PHP模板移植到Java语言。
JDynamiTe的模板定义和PHP Template有些微小的差别，但一样简单。我阅读了JDynamiTe的例子代码，马上喜欢上了这种方法。
但我发现，JDynamiTe有一点不足。和DOM结构的处理过程一样，JDynamiTe的模板部分和参数设置部分是合在一起的。JDynamiTe的模板部分不能在多线程中同时使用。
每次JDynamiTe都需要读取并解析HTML文件，生成一个模板，设值之后，产生结果。处理过后的这个模板就不能再直接使用了（也许可以清空再使用）。
如果HTML文件很大，那么，读取并解析HTML文件要花费不少时间。
所以，我决定自己实现一个高效率的可重用的PHP Template Java Port。
项目名为fastm（Fast Template的意思。）
2.10. fastm
http://sourceforge.net/projects/fastm
http://sourceforge.net/projects/lightweb
fastm的模板定义采用JDynamiTe的模板定义，而且我直接采用JDynamiTe的例子模板文件，作为fastm测试例子的模板文件。fastm可以说是JDynamiTe的一个Multiple Thread Port。
在fastm里，我把HTML的解析结果文档 （Template DOM）和变量设值部分（ValueSet DOM）分开。
每个HTML文件只需要解析一次，生成一个只读的模板。既然只读，当然线程安全，任何数量的线程都可以同时使用这个模板。
以后这个模板只需要和不同的变量设值结合，就可以生成不同的结果。
模板的解析过程，采用按行读取处理的方式，解析的速度很快。
fastm的速度会比JSP + TagLib快。fastm的速度可能会比纯粹的JSP慢，也可能更快一些。JSP（即Servlet）把整个页面一行一行地写到Response里面，网络传输的效率不高(当然，也有可能用到HTTPResponse的buffer)。而fastm把整个页面或者整块页面，一次写到Response里面，网络底层协议尽可以优化分块，达到最好的网络传输效率。
fastm支持动态生成JavaScript。这是PHP和JDynamiTe无能为力的地方。
fastm支持JavaScript的注释定义。比如，
// BEGIN DYNAMIC: special_code
…..
// END DYNAMIC: special_code
这一块将被标志为动态块。
fastm的页面定义完全仿照JDynamiTe的PHP页面定义。我的思路来源是PHP Template和JDynamiTe。我自己原创的东西是fasm的实现，和使用方法。fastm的代码量很小，采用的技术也很简单，没有用任何第三方的软件，只用了JDK1.4本身的类。
fastm是DOM & PHP思路上的又一次飞跃——Template DOM 和ValueSet DOM的分离。
在我目前所知的Java页面生成技术中，我相信，fastm从各方面来说，是最好的方法——快，易用，灵活，强大。我期望fastm这种页面生成方式，能够较好地解决页面生成技术这个令人头痛的问题，能够在全世界的程序员中流行起来。
发表于 @ 2004年07月07日 17:30:00|评论(loading...)|编辑