分享
 
 
 

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

王朝java/jsp·作者佚名  2006-01-30
窄屏简体版  字體: |||超大  

变革性的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)过了一段时间,人们又觉得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可视插件的技术厂商,技术市场一片繁荣。

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

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

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

2.fastm的诞生——“简单就是美”王者归来 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开源项目诞生了。

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]

看起来,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呢?^_^

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有