Web显示层技术评估 -- 9.Browser Side, 10, Unobtrusive, 显示逻辑AOP, 多语言支持的终极解决方案, 总结与展望

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.charpter<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="1" unitname="”">1”</chmetcnv>>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显示技术的总结和展望。

本文到这里结束。