CSDN博客

img buaawhl

变革性的Java Web模板技术 -- fastm

发表于2004/7/14 9:16:00  17337人阅读

分类: fastm -- leading java web page tech

变革性的Java Web模板技术 -- fastm

1.“简单就是美”空想(响)曲

 

在软件设计领域中,有一句脍炙人口的至理名言——简单即美好。

几乎所有的软件设计大师,都会在其著作中训导读者:

“简单即美好”,

Keep it simple, Stupid”,

Less is more”,

…..

 

这是一条耳闻能详,人人都会说的至理名言。

但实际上,这也是一条被违背得最广泛、最彻底的至理名言。

“简单就是美”这个真理就好像天堂一样,人人都说天堂美好,但人人都拼命拖延到达天堂的时间。

 

从总体趋势来讲,软件开发技术总是变得越来越复杂,越来越庞大。

我们来看Java Web表现层技术的发展历史。

1)首先,Servlet诞生了。Web程序员们很高兴,觉得用起来比CGI爽多了。

2)过了一段时间,人们就觉得在Java程序里面写HTML太不爽了。毕竟,在HTML中,静态的文本标签占大部分,动态显示部分只是小部分。不如在HTML里面写Java代码。于是,JSP诞生了。成为了ASP的一个有力竞争对手。

3)过了一段时间,人们又觉得HTMLJava代码混杂在一起,不仅页面结构很差,而且其中的Java代码也很难维护。这就是著名的“Java Code Pollution”问题。不如用自定义的XML元素替换Java代码,这样,整个页面就XML化了。于是,TagLib就出现了。

4)可还是有一个问题,TagLib不能在一般的HTML浏览器或编辑器里面显示,页面不能所见即所得。而ASP.netVisual Studio快速可视开发之优势,正在Web开发领域攻城掠地。Java世界仓促应战,启动JSF项目。成员众多的Web Framework阵营中又多出一位权威的重量级选手。

 

各种新概念层出不穷,页面流程越来越复杂。

据说这是为了降低开发难度,让程序员只关注于业务逻辑,而不用关心底层的技术细节;据说这是为了企业级应用,而企业级应用的需求是复杂的,所以,把简单问题复杂化是有道理的——据说,这是为了系统的面向未来的可扩展性、可伸缩性….

 

这是个神话广为流传的年代,这是个概念批量制造的年代。

 

深度思索一番,我想,技术的复杂化趋势,也许是技术市场的商业内需所致?

 

新技术出现的驱动力一般有两种:

1)第一种驱动力是为了解决真正的问题。

比如,Servlet的出现,是为了解决CGI的空间时间消耗问题。较CGI而言,Servlet是一种新思路,一种替代技术。

第一种驱动力来带来的新技术的产生周期比较长,不足以维持人们对技术的需求。

 

2)第二种驱动力是为了弥补前一个技术的不足。

复杂的技术总有一些不足之处,于是为下一次技术革新创造了内需。而且,技术越复杂,不足之处就越多,技术“创新”(或者叫“修补”更合适?)的内需和商机就越大,形成一条自产自销的技术“修补”产业链。

比如,JSP的出现是为了辅助生成Servlet;而TagLib的出现则是为了弥补JSP的不足;TagLib可视化插件则是为了弥补TagLib的不足。商机无限,涌现出一大批提供各种TagLibTagLib可视插件的技术厂商,技术市场一片繁荣。

这第二种驱动力带来的新技术的产生周期比较短,而且子子孙孙无穷匮也,绝无断炊之虞。

 

但我坚信,技术总有一天要返朴归真。

总有一天,我们会回到真正解决问题的道路上来,而不是继续一条技术“修修补补”之路。

2fastm的诞生——“简单就是美”王者归来

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表现层技术:

 

1Velocity http://jakarta.apache.org/velocity/  (and WebMacro, FreeMarker.. etc)

2Tapestry http://jakarta.apache.org/tapestry/

3Echo http://sourceforge.net/projects/echo

4Cocoon (XML + XSLT) http://cocoon.apache.org/

5XMLCStatic DOM  http://xmlc.enhydra.org/

6NekoHTML (Dynamic DOM) http://www.apache.org/~andyc/neko/doc/html/

7JDynamiTePHP Template Porthttps://sourceforge.net/projects/jdynamite

 

通过研究比较,我发现了模板技术中的“万恶之源”——模板里包含的逻辑代码(if, else, for, 赋值, 操作, 调用等)。

这些包含在模板里的逻辑代码,是“所见即所得”开发的天敌,也是毁坏重用性的罪魁祸首。

 

JSP + TagLibVelocityTapestryXSLT等都是含有逻辑的模板。如果没有特殊的插件,这些模板都无法正确在普通的HTML浏览器或编辑器正确显示。

而且,混杂在HTML中的逻辑是没有办法重用的;你无法把这些逻辑分离出来为通用的方法或类。

 

JDynamiTe是一个把PHP模板技术移植到Java的一个开源项目。JDynamiTe模板用注释(BEGIN-END)标记动态块,用{}标记占位变量。JDynamiTe模板不包含任何逻辑,是“所见即所得”的模板技术,能够在普通的HTML浏览器或编辑器正确显示。

XMLCDOM模板技术直接使用HTML文件作为模板,当然也是“所见即所得”的模板技术。

JDynamiTeXMLC的共同点是,模板中不含有任何逻辑,所有的模板处理逻辑(检查判断、节点拼装、变量替换等)全在代码中完成。

 

这两种技术虽然把逻辑从模板定义中分离了出去,但用法上却没有把逻辑和数据从模板中彻底地分离出去。

我们来看XMLC技术中的HTML DOM的用法。一份HTML DOM刚生成的时候,还是一个纯洁的模板。但随后,程序就直接改动HTML DOM的节点数据,甚至改变节点的位置和数量,这份HTML DOM再也不能当作一个纯洁的模板重用了,更别说在多线程的环境中被多个线程同时使用了。想想看,在一个静态文本占绝大部分的DOM结构里,这种做法将造成多么大的空间和时间上的浪费。

JDynamiTe的用法具有和XMLC同样的性能问题。

 

我冥思苦想如何解决这种性能上的缺陷,最后,在JDynamiTePHPDOM的思路的基础上,我创造了Template DOMValueSet DOM的概念,从用法上,进一步把数据和逻辑从模板中彻底地分离出去。于是,fastm开源项目诞生了。

3.小、快、简、易、强的“银弹”— fastm

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]

 

看起来,fastmTemplate 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 DOMValueSet 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 DOMTemplate 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 DOMTemplate DOM的分开,是一个极大的思路上的创新和飞跃。

毕竟,页面中的动态部分,和静态比起来,是非常小的一部分。ValueSet DOM代表动态部分,由程序随时生成,可以存在多份。Template DOM代表静态部分,只需要解析一次,而且只需要一份。

 

ValueSet DOMTemplate DOM的分开,更是一种前所未有的彻底的显示和数据的分离。比XML/XSLT的方法更加彻底。XML确实是纯粹的数据,但XSLT中却不可避免的要包含逻辑。ValueSet DOM是纯粹的数据,没有任何逻辑,Template DOM是纯粹的显示模板,也没有任何逻辑。

 

由于数据结构是DOM结构, fastm实现TilePortal等功能,可以说是Super Easy。你绝没有必要把页面组装逻辑别别扭扭地写在一堆复杂的TagLib里面,你可以大大方方地把页面组装逻辑写在一个很小的公用方法里面。

 

3.3 fastm资源列表

http://sourceforge.net/projects/fastm

用户可以从这个地址下载fastmfastmweb的源代码文件、使用文档。

其中的fastmwebfastm的辅助项目fastmweb,帮助定义装载Web环境中的fastm模板。同Velocity一样,用户可以在任何web framework中使用fastm模板技术。

 

http://sourceforge.net/projects/lightweb

lightwebfastm作者开发的一个轻量级的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.netWeb开发领域夺走的领地,改变两大阵营的力量对比。

fastm足以与Visual Studio.netASP)相较,甚至更胜一筹。

fastm模板不需要任何特殊的支持,就能够在普通浏览器中“所见即所得”;ASP模板必须在Visual Studio.net中才能正确显示(而且是以form的形式显示)。

fastm模板比ASP模板简单多了。从用法来说,甚至比其源头PHP模板还要简单。使用fastm,大量的PHP程序员可以直接转到Java Web开发阵营,而不用学习那些庞杂复杂的新模板技术。

JSR-223是一个JavaPHP等脚本语言(还有PerlPythonRubyTcl)等互操作的JSRhttp://www.jcp.org/en/jsr/detail?id=223 目前正处于初稿审定阶段。

这从另一个方面说明,fastm生逢其时,直接为JavaPHP程序员提供Java NativePHP改进模板。

至于fastm是否会令Java Web程序员贬值。我想,可能会让某些复杂技术的专精高手(比如JSP调试高手,各种TagLib使用高手)贬值。但fastm不会令解决真正问题的高手贬值,相反,fastm会帮助这些高手把精力更集中在解决真正的问题上。

 

关于目前如火如荼的JSF,我很高兴看到这个功能强大的开发框架的出现。

但说实话,我不认为,TagLib可视化拖放开发足以和Visual Studio.netASP)竞争。那等于以己之短,较人之长。

而且,一个潜在的危险是,Java Web开发框架将被引上一条微软倡导的“C/S结构、桌面客户端”的不归之路。

 

目前的一个趋势是,B/S开发框架尽量向C/S开发框架靠拢。

几乎所有的现代Web开发框架都在努力地追求着基于事件机制的处理方式——把前台页面组件和后台处理代码绑定在一起。

Visual Studio.netASP开发工具是一个典型的类C/SB/S开发结构。JSFWebapp开发工具部分也亦步亦趋,跟着走上了这条路。

不仅在服务端的开发框架存在这种趋势,在客户端这种趋势也愈演愈烈。继ActiveXApplet之后, XMLHTTPFLEX等新一代的“浏览器插件客户端技术”方兴未艾。

开源社区Mozilla提出并支持XUL技术。微软的LongHorn 64位操作系统提出“桌面即浏览器”(其实等于宣告浏览器的消亡),力推XAML

HTML不被双方看好。HTML前景堪忧。

一种可能性:将来HTML很可能只作为一种历史资料的记录格式而存在,而不会作为应用程序的UI存在;而HTML浏览器也只将作为一种历史资料查看器而存在;HTML B/S Webapp时代结束。

 

可以说, B/S Webapp正是毁于自身越来越复杂的内需和开发结构。

B/S Webapp的界面的互操作性要求越来越强,浏览器需要支持的特性越来越多,附带的插件也越来越多(Java ScriptActiveXFlashXUL)。既然这样,为什么还用浏览器?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就随之淘汰了。TapestryXMLCEcho也随之淘汰了。

XML + XSLT的项目也许还能够幸存——比如,改造XSL,输出XULXAML

fastm当然也会幸存——fastm也能够“所见即所得”地生成XULXAML。只要有动态生成可视化XML UI的需求,fastm就有用武之地。

 

如果B/S Webapp注定要退出历史舞台,fastm也无力挽救,但fastm至少可以拖延这个过程。fastm极低的技术门槛能够吸引大量的页面开发人员,留连在HTML B/S Webapp的领域里。

而且,fastm既属于现在,又属于未来。既可以用作构建现在的HTMLWML UI,也可以用于构建将来的XULXAML UI

 

在这样的朝不保夕的严峻形势下,为什么不选择fastm呢?^_^

 

1 0

相关博文

我的热门文章

img
取 消
img