fastm具有其它页面生成技术不可比拟的优越性：
所见即所得，易学易用，开发速度快，运行空间小，运行速度快，模板与数据的彻底分离，模板与数据的多对多自由匹配。
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]
<select name=”zipcode”>
<!-- BEGIN DYNAMIC: zipcodes -->
<option value=”{zipcode}”>{zipcode}</option>
<!-- END DYNAMIC: zipcodes -->
</select>
[/code]
这个片断包含一个BEGIN-END块（zipcodes），这个块里包含两个相同的变量{state}，其它的部分都是静态文本。
这个片断的fastm Template DOM结构如下：
[code]
静态文本 <select name=”zipcode”>
动态块zipcodes --
| --- 静态文本 <option value=”
| --- 变量{zipcode}
| --- 静态文本 ”>
| --- 变量{zipcode}
| ---静态文本 </option>
静态文本 </select>
[/code]
看起来，fastm的Template DOM也没有什么特殊的。
但Template DOM具有一个至关重要的特性——只读，不可改变。
既然只读，那么当然线程安全，同一份Template DOM能够同时被多个线程并发使用。
那么我们如何从只读的Template DOM得到动态页面呢？我们必须把动态数据装载到一个ValueSet DOM结构（也是一个树型结构）中，然后用这个ValueSet DOM匹配Template DOM，生成动态结果。
3.2 Template DOM + ValueSet DOM = Dynamic Result
Template 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(); // 对应 动态部分zipcodes
for(int i = 0; i < zipcodes.length; i++){
IValueSet item = new ValueSet();
item.setVariable(“{zipcode}”, zipcodes[i]);
items.add(item);
}
top.setDynamicValueSets(“zipcodes”, items);
我们把top这个ValueSet DOM和Template DOM结合起来。就生成如下结果。
[code]
<select name=”zipcode”>
<option value=”361005”>361005</option>
<option value=”10008”>100008</option>
</select>
[/code]
一份Template DOM可以匹配多个ValueSet DOM。同样，一个ValueSet DOM也可以匹配Template DOM，把相同的数据显示在不同风格的模板中。
比如，我们还有这样一个HTML片断：
[code]
<table>
<!-- BEGIN DYNAMIC: zipcodes -->
<tr><td>{zipcode}</td></tr>
<!-- END DYNAMIC: zipcodes -->
</table>
[/code]
我们把上面的top ValueSet赋给这个模板。得到的结果如下。
[code]
<table>
<tr><td>361005</td></tr>
<tr><td>100008</td></tr>
</table>
[/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资源列表
http://sourceforge.net/projects/fastm
用户可以从这个地址下载fastm和fastmweb的源代码文件、使用文档。
其中的fastmweb是fastm的辅助项目fastmweb，帮助定义装载Web环境中的fastm模板。同Velocity一样，用户可以在任何web framework中使用fastm模板技术。
http://sourceforge.net/projects/lightweb
lightweb是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 Studio.net（ASP）相较，甚至更胜一筹。
fastm模板不需要任何特殊的支持，就能够在普通浏览器中“所见即所得”；ASP模板必须在Visual Studio.net中才能正确显示（而且是以form的形式显示）。
fastm模板比ASP模板简单多了。从用法来说，甚至比其源头PHP模板还要简单。使用fastm，大量的PHP程序员可以直接转到Java Web开发阵营，而不用学习那些庞杂复杂的新模板技术。
JSR-223是一个Java与PHP等脚本语言（还有Perl，Python，Ruby，Tcl）等互操作的JSR。http://www.jcp.org/en/jsr/detail?id=223 目前正处于初稿审定阶段。
这从另一个方面说明，fastm生逢其时，直接为Java和PHP程序员提供Java Native的PHP改进模板。
至于fastm是否会令Java Web程序员贬值。我想，可能会让某些复杂技术的专精高手（比如JSP调试高手，各种TagLib使用高手）贬值。但fastm不会令解决真正问题的高手贬值，相反，fastm会帮助这些高手把精力更集中在解决真正的问题上。
关于目前如火如荼的JSF，我很高兴看到这个功能强大的开发框架的出现。
但说实话，我不认为，TagLib可视化拖放开发足以和Visual Studio.net（ASP）竞争。那等于以己之短，较人之长。
而且，一个潜在的危险是，Java Web开发框架将被引上一条微软倡导的“C/S结构、桌面客户端”的不归之路。
目前的一个趋势是，B/S开发框架尽量向C/S开发框架靠拢。
几乎所有的现代Web开发框架都在努力地追求着基于事件机制的处理方式——把前台页面组件和后台处理代码绑定在一起。
Visual Studio.net的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 Studio.net，还是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。
在这样的朝不保夕的严峻形势下，为什么不选择fastm呢？^_^
