Browser Side
同Server Side的技术格局恰好相反， Browser Side的HTML DOM Manipulation技术、HTML View Model技术比较多，比较流行。各种JavaScript UI控件，DOM绑定控件，这方面的库很多，而且很酷。这里不再列举了。
Browser Side的Scripted Template技术就比较少见了。我知道的大概有下面几个。
TrimPath的JST
http://www.trimpath.com/project/wiki/JavaScriptTemplates
语法举例
<option value="${country.name}" {if country.name == currCountry}selected{/if}>
Helma
http://dev.helma.org/Wiki/JavaScript+Template+Engine/
语法举例
<% if (session.user != null) %>
Hello <%= session.user.name %>
<% else %>
<a href="/login">Login</a>
<% end %>
SWATO
http://swik.net/SWATO/Swato+JavaScript+Template
语法举例
#for (i in products) {
# var p=products[i];
<td>$<%p.price%></td><td><%p.quantity%> : <%p.alert%></td>
</tr>
#}
以数据为中心的Ajax应用中（把数据取过来，而不是取一段HTML，或者一段Script），当页面布局结构比较复杂的情况下，也可以选择Browser Side XSL。
一个有趣的联想是DOMPlus的思路。
DOMPlus不仅支持DOM + DOM = SAX，而且支持DOM + DOM = DOM。
这个特性特别适合于Browser Side。假设存在DOMPlus的Javascript版本。
Javascript从Server Side拿来XML Data，和Browser里面的一段HTML进行一下Match，显示就搞定了。不需要写任何代码。
Unobtrusive
在Brower Side方面，Scripted Template技术并不流行。
这个事实说明了，Browser Side的显示技术更加归于常态，显示模型更加自然。
JavaScript编程有个流行的概念，叫做Unobtrusive，就是我们常说的无侵入性。
JavaScript, HTML, CSS清晰有效的分开。
行为的归行为，内容的归内容，风格的归风格。
凯撒的归凯撒，上帝的归上帝，人民的归人民。
各自照看好自己的领域，而不侵入他人的领域。
无侵入，POJO等概念，在Server Side方面（比如Java），也是甚嚣尘上，炒作的不亦乐乎。
但是在Web显示技术的方面，Unobtrusive无侵入特性，不能不说，Browser Side由于先天的JavaScript操作DOM的优势，已经走在了前面。
虽然JavaScript作为一门动态语言，开发效率自然超过强类型编译语言，但是代码维护、IDE提示、辅助重构方面的成本也不可低估。
所以，Server Side的显示技术，仍然是不可缺少的。在Server Side同样应用Unobtrusive原则，也仍然具有重要的意义。
前面提到的两个指标，Template Purity模板纯净度, Action Code Purity用户代码纯净度。
就属于Unobtrusive指标。
显示技术里面，代码逻辑表示动态部分，复杂部分；Template表达静态部分，简单部分。
所以，人们更加关注代码逻辑的容易管理的程度。
由于代码逻辑在IDE里面相对容易管理。人们更能够容忍Java 或者Java Script代码里面出现具体的Template Node，而觉得Template里面的Script比较难以管理。
Scripted Template基本上是Obtrusive的，对Template的侵入性最强。虽然Template操作没有侵入到Java 或者 JavaScript代码。
这叫做 1 -- Way Obtrusive
Template Manipulation大致能够做到对Template的Unobtrusive非侵入，虽然他们的Template Node操作侵入了Java 或者Java Script代码。
这叫做1-Way Unobtrusive。
Model Match技术具有最好的Unobtrusive非侵入特性。Java或者JavaScript代码不侵入Template到里面，具体的Template Node操作也不侵入到Java或者JavaScript代码里面。
这叫做2-Way Unobtrusive。
Fastm, DOMPlus是天生的Model Match, 具有2-Way Unobtrusive特性。
Wicket也是天生的Model Match，大致能够做到 1.5 -Way Unobtrusive。
如果严格限制不采用Logic Taglib, Tapstry Logic Tag，那么Taglib，Tapestry也能够做到1.5 – Way Unobtrusive.
显示逻辑AOP
这个需求主要包括页面数据类型的统一格式化。
比如，所有类型为Date，名字以Time结尾的数据（startTime, endTime等），都显示到秒钟；Day结尾的时间字段(registerDay, birthDay等)，都显示到天。Period, Quarter, Year结尾的字段也都有不同的显示需求。
能够支持自定义显示逻辑AOP Interceptor的技术并不是很多。
XSL语法天生就是AOP语法，Declaring，Pattern Match，用法就是要求程序员编写Interceptor。
Fastm, DOMPlus对这方面也支持的很好。同样是采用自定义Interceptor。
W3的DOM Level 2规范定义了DOM Traversal。
http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/traversal.html
DocumentTraversal, TreeWalker, NodeIterator, NodeFilter。
使用Pull模型（SAX是Push模型）处理XML的程序员，可以使用NodeFilter来过滤掉不需要显示的节点。NodeFilter毕竟只是一个Filter，只能对Node内容进行简单的开关选项处理，YES, or No，显示或者不显示。只是作为DocumentTraversal的whatToShow参数的一个补充。AOP能力很有限。
多语言支持的终极解决方案
多语言支持，也叫做国际化，本地化。
一般采用字典文件的做法。比如，dict.en, dict.cn, dict.fr, dict.de, dict.jp等。
在这类做法里面，Template里面通常都只有Message Key。
<span>< message key=”name” /></span>
有些更好的做法是这样，提供缺省文本信息。
<span id=”key.name”>用户名称</span>
这样能够保持页面的一目了然。
除了字典文件的做法之外，另一种做法是直接把文字资源，存放到Template里面。
然后分多个目录。En, cn, fr, de, jp等目录，下面全都是对应的Template文件。
这种方案叫做语言目录方案。
这种方案的缺点很明显，一个文件的改动，要扩散到所有的对应文件中。
这种方案的优点也很明显，文件内容一目了然，尤其是支持所见即所得的模板。另一个优点就是运行效率。字典文件方案运行的时候，需要进行大量的查字典，动态替换文本工作。而语言目录方案的模板里面大部分都是静态文本。
有没有一个两全其美的方案？答案是，有。
首先，我们采用自己的母语（比如，中文）作为主模板文件，都放在cn目录下。
然后，其中需要多语言的文本信息，都采用下面这种方式包装起来。
<span id=”key.name”>用户名称</span>
<p id=”key.help.charpter1”>long text about system help</p>
这时候，Template仍然保持了所见即所得的特性。然后，我们根据这些Key，做其他语言的字典文件。Dict.en, dict.jp, dict.fr, etc.
然后我们用一个文本处理引擎，替换掉这些多语言信息。为每一种语言产生一个目录，下面都是对应的语言的Template文件。比如，en, jp, fr, 等Template文件目录，里面都是对应的填充了内容的模板。打开一看，一目了然。
当然，这个处理过程中，并没有影响那些动态数据部分，而只是替换了静态文本部分。
每次只需要更改主要语言目录的文件，然后用引擎处理，变化自动分布到其他语言目录。
这种技术的关键在于，Template本身是否可再生资源？能否被多次处理？能否被统一处理？
有几种技术是具有这种可能性的。
Taglib理论上可以被当作XML文件处理，具有理论上的可行性。
Fastm, DOMPlus具有现实可操作性。Fastm, DOMPlus都可以自定义标签，处理动态部分的同时，也能够忽略其他动态部分。
总结与展望
本文分析了Web层显示技术的各类指标和特性。
本文的讨论目前还只是局限于一般的B/S结构。
Web Service, SOA代表了Web未来发展的趋向。数据整合，流程整合，各类资源整合。
界面UI也不会限于HTML一种，XUL, XAML, SVG, RSS等也有各自的应用。
我们都知道Web中有一种“盗链”的现象。
一个网站，不是通过Copy，而是直接通过Link引入了其他网站的资源，比如CSS，图片资源等。这样可以节省自己的Server资源。
有些技术更狠，能够抓取别人的页面内容，剪贴拼凑之后显示在自己的网页上。
这种情况实际上是一种偷偷摸摸的不被允许的资源共享实践。
Web Service把这种实践发展成了一种商业模式，资源共享模式。不仅可以共享数据和资源，而且可以共享内容和服务（比如Portlet）。
比如，Web Service Remote Portal，就是一种内容提供模式、服务提供模式。网站流量不再依靠用户点击率来计算，而是依靠Web Service调用率。
我们来看看，能够共享的资源有哪些。
CSS, 图片，JavaScript等可以直接Link过来；数据、内容可以抓取过来。
其中以CSS的共享最为流行。CSS + 图片 + 某些文字替换，组成了一个Theme（显示主体），或者Skin（表观）。很多人津津乐道，并孜孜不倦地谈论、应用、提供各种Themes, Skins。
但是还有一个重要的资源共享没有得到充分的发展。就是Template Layout的共享。
目前，Web Server的Template资源，一般都存放在自己的文件系统中。
假设这样一种方式。
一个Web Server运行的时候，通过Web Service获取数据，通过Link引用CSS，JS，图片等，通过XLink + XPointer + XPath获取一份XML Node or Fragment or Text，作为Template Layout，自己的服务器上只需要一份Display Logic把这些东西组装起来，就可以把页面发布出来。甚至Display Logic也可以从Web Service获取（Script等，当然这里面涉及到安全问题），自己只负责统筹管理安排调用。
这种模型对于Web Service Client来说，也是适用的。
这种模型的关键就在于，Unobtrusive。所有领域都是清楚地分开，Domain Specific，决不侵入到其他领域，也不允许其他领域的侵入。
以上是我对Web显示技术的总结和展望。
本文到这里结束。
发表于 @ 2006年07月14日 14:47:00|评论(loading...)|编辑