扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
在软件设计领域中，有一句脍炙人口的至理名言——简单即美好。
几乎所有的软件设计大师，都会在其著作中训导读者：
“简单即美好”，
“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可视插件的技术厂商，技术市场一片繁荣。
这第二种驱动力带来的新技术的产生周期比较短，而且子子孙孙无穷匮也，绝无断炊之虞。
但我坚信，技术总有一天要返朴归真。
总有一天，我们会回到真正解决问题的道路上来，而不是继续一条技术“修修补补”之路。
Java世界是一个开放的世界。我想，正是因为这一点，广大的Java程序员才舍不得离开这个Java开发阵营。
java.sun.com公布了所有的java技术规范。
apache.org开源社区吸引了大量的程序员加入Java开发阵营。
sourceforge.net为更广大的程序员（不仅是Java）提供了交流、共享和发展的空间。
正是因为这样的开放性，促进了Java开发技术的空前发展。
也正是因为这样的开放性，形成了Java Web表现层技术群雄逐鹿的局面。
在Java Web表现层技术领域，JSP+TagLib页面技术是权威，是规范，但这个领域也不排斥其它的技术。
如上所述，JSP+TagLib并不是完美的技术，所以具有不断改进发展的内在需求。
同时，这一点也促使人们不断探索、比较其它的技术可能性。
Web表现层之下的所有层次——O/R层、业务层、Web Framework等都直接由Java代码实现，都能够很好的结构化，对象化，不存在任何问题。唯独Web表现层，天生结构松散，野性难驯。
我是一个Java Webapp程序员，一直执著地努力把Web表现层做得具有同样的结构化，对象化。两三年来，我应用、研究、比较了多种Web表现层技术：
（1）Velocity http://jakarta.apache.org/velocity/ (and WebMacro, FreeMarker.. etc)
（2）Tapestry http://jakarta.apache.org/tapestry/
（3）Echo http://sourceforge.net/projects/echo
（4）Cocoon (XML + XSLT) http://cocoon.apache.org/
（5）XMLC（Static DOM） http://xmlc.enhydra.org/
（6）NekoHTML (Dynamic DOM) http://www.apache.org/~andyc/neko/doc/html/
（7）JDynamiTe（PHP Template Port）https://sourceforge.net/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开源项目诞生了。
fastm具有其它页面生成技术不可比拟的优越性：
所见即所得，易学易用，开发速度快，运行空间小，运行速度快，模板与数据的彻底分离，模板与数据的多对多自由匹配。
fastm从各方面来说，是最好的模板技术——最快，最小，最易用，最灵活强大（和纯Servlet/JSP一样灵活强大）。我期望fastm这种页面生成方式，能够较好地解决Web页面生成问题，能够在全世界的Java Web程序员中流行起来。
上面这段话是否只是不自量力的自卖自夸？
这点很容易辨别：fastm是完全开放的一个开源项目，一试便知。由于fastm的思路、实现和用法简单易懂，这一试也花不了什么时间。
fastm真正地证明了“简单即美好”。下面我具体讲解一下fastm的思路和用法。
（1）静态文本。
（2）占位变量。用{}标志。
（3）动态块。用BEGIN-END DYNAMIC标志。
其中，动态块可以包含其它的元素——子动态块，占位变量，静态文本。所以，fastm模板是一个树型结构，相当于一个轻量级的DOM结构。后面我们就称这个结构为Template DOM。
下面举个简单的例子。比如下面的HTML片断。
[code]
<select name=”zipcode”>
<!-- BEGIN DYNAMIC: zipcodes -->
<o
<!-- END DYNAMIC: zipcodes -->
</select>
[/code]
这个片断包含一个BEGIN-END块（zipcodes），这个块里包含两个相同的变量{state}，其它的部分都是静态文本。
这个片断的fastm Template DOM结构如下：
静态文本 <select name=”zipcode”>
动态块zipcodes --
| --- 静态文本 <o
| --- 变量{zipcode}
| --- 静态文本 ”>
| --- 变量{zipcode}
| ---静态文本 </o
静态文本 </select>
[/code]
看起来，fastm的Template DOM也没有什么特殊的。
但Template DOM具有一个至关重要的特性——只读，不可改变。
既然只读，那么当然线程安全，同一份Template DOM能够同时被多个线程并发使用。
那么我们如何从只读的Template DOM得到动态页面呢？我们必须把动态数据装载到一个ValueSet DOM结构（也是一个树型结构）中，然后用这个ValueSet DOM匹配Template DOM，生成动态结果。
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结合起来。就生成如下结果。
<select name=”zipcode”>
<o
<o
</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里面，你可以大大方方地把页面组装逻辑写在一个很小的公用方法里面。
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）中运行。
我确信，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 Scri
微软把握并引导这个趋势，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呢？^_^
如果您非常迫切的想了解IT领域最新产品与技术信息，那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击｜2021世界人工智能大会
直击5G创新地带，就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020（Cloud）- 科技行者
京公网安备 11010802021500号