Web显示层技术评估 -- 1. 名词界定 2. 理论模型, 3. 数据寻址

Web显示层技术评估

名词界定

显示层的意思就是Presentation Layer，也翻译成表现层、展现层、展示层。

本文讨论的范围只包括采用HTML Template的显示层技术，不包括Echo，GWT(google web toolkit)等根据代码产生HTML的工具。

本文主要讨论Server Side (针对Java Language)的显示层技术，然后进一步讨论Browser Side（Ajax）的显示层技术（一个典型的Ajax应用也分为Model, View, Controller – Data, HTML/CSS, JavaScript）。注意，本文关于Ajax的讨论只有很少一部分，因为我不擅长这个领域。只是一个顺便的扩展比较。

一个很有趣的现象。Server Side和Browser Side的显示层技术格局恰好相反。Server Side的Scripted Template技术比较多，比较流行；而Browser Side的HTML DOM Manipulation技术、HTML View Model技术比较多，比较流行。

本文会提到一些技术、或者框架的名称，但只局限于讨论该技术、该框架的显示相关部分的内容，而不涉及评估其他方面的特性。比如，本文不讨论Link URL Generation, Action URL Generation，Button Script Generation这些页面组件事件机制的方面。

本文是一个深度讨论。不讨论简单的替换个字符串的Hello World案例，而是穷尽各种显示层技术的能力极限，探索它们在复杂布局（动态include等）、复杂显示逻辑（条件、循环、嵌套、递归）等方面的功能。

对了，（考虑到Site Mesh，Struts Tiles Taglib等技术广泛的群众基础），可能需要专门提一下，本文将不讨论Site Mesh，Tiles等布局技术（named include）。

Site Mesh相当于XSL的一个简化版本，只保留了根据(name->file)配置替换某个HTML Node的能力，其余的如Tiles，也大致如此，由于多了一个(name->file)配置文件，比直接include file高级了不少。

由于使用简单（功能自然也简单），这类技术获得了广大群众的支持，呼声很高。本文为忽略了这一类技术感到很遗憾。

另外需要指出的是，并不存在一个十全十美的方案。

工作总是要做的，不是在Template里面做，就是在Java Code里面做，总之，总要找个地方做这个工作，天下没有免费的午餐。一方面特性增强了，自然影响到另一方面。

正如，代码的耦合实际上并不能完全消除，我们只能把这些耦合点移动来移动去，今天我看这里不舒服了，把耦合点移动到另一个地方；明天另一个人看到那里不舒服了，又移动回来。而且各自都能说出一大堆道理。

所以，需要注意的是，并不存在一个绝对的优胜方案。本文只是列出各种技术指标的参考评估数据，以便帮助读者根据自己的需要，做出比较准确的评估。（是的，准确的量化评估，而不是广告语或者口号）

理论模型

一个显示的整个过程，如果用一个函数来描述，那么看起来大概是这样。

F(Data, Template, Display Logic) => Result HTML

其中的Display Logic，就是显示逻辑。Display Logic操作Data和Template，产生最终结果。

这个Display Logic可能以各种形式出现在任何地点。

比如，可能作为Server Side Script存在于Template里面，把Data取出来输出；也可能存在于后台Java里面，根据Data操作Template Node。

针对前一种情况，函数公式表达是：Template Script (Data) => Result

针对后一种情况，函数公式表达是：Logic (Data, Template) => Result

这个模型可以作为显示层技术的划分标准。

(1) Scripted Template

HTML和Server Side Script混杂在一起的显示层技术。

包括JSP, Velocity, Freemarker, Taglib, Tapestry, XSL等。

肯定有人对这个划分有异议。XSL里面有choose, if, for。这还好说。尤其是对Taglib, Tapestry，反映可能更加强烈。我似乎已经看到，Taglib or Tapestry Fans已经跳起来了，高叫着，Taglib or Tapestry明明是组件技术，组件技术，组件技术….

这里我还是表示很遗憾。在目前定义的这个狭义模型下，任何Template中包含Logic的显示技术都划为Script这一类。而且在表示逻辑的时候，这类组件技术表现的更加突出一些。

比如Tapestry的<foreach> <if><if-not> <let><set> 等逻辑标签。尤其是这个if not，是专门多出来的一个条件语句，一般的编程语言里面都不具备这样的对应语法。当然，Tapestry并不专美，Taglib的Logic Tag也是如此。

(2)Template Manipulation

Java代码直接操作Template（比如，HTML DOM）产生结果的显示层技术。

包括XMLC, JDynamiTe, Rife等。

大家对这一类技术可能不是很熟悉。后面进行特性分析的时候，会举出一些典型的例子，来说明各自的用法。

一个很有意思的现象是，在Browser Side（Ajax），由于Java Script操作HTML DOM非常方便，这类显示技术非常普遍。相反的，Scripted Template的技术，在Browser Side却不多见。后面讨论Browser side的时候，会列举一些典型的例子。

(3) Model Match

Java代码负责提供符合显示层要求的Data Model，显示层框架本身把Data Model和Template进行匹配，产生结果。

包括Wicket, Fastm, DOMPlus, 等。

Wicket如同Swing的用法，需要为不同的UI Component提供不同的View Model，比如Table, List, Label等。Fastm, DOMPlus支持POJO，但同样需要满足一些框架特有的约定。

也许有人会说，某些Display Tag Lib, Tapestry Components可能也需要Java Code提供特殊的View Data Model。

不过，需要特殊的View Data Model，并不是一个好的特性，意味着不支持POJO。

数据寻址

在正式开始之前，先说明一下数据寻址的概念。

数据寻址，意思是数据访问、属性获取等。主要包括两类风格。

(1) OGNL Style

http://www.ognl.org/

OGNL (Object Graph Navigation Language)如此著名和深入人心，以至于我在这里用OGNL Style代表Java Bean属性寻址的方式。

比如，a.b[1].c.d[2].name

另一类当然是

(2)XPath Style

比如，a/b[1]/c/[d]/@name

XPath Style主要应用在XSL中。

一个JXPath项目能够按照XPath的方式访问Java Bean属性。

http://jakarta.apache.org/commons/jxpath/

简单的寻址，OGNL和XPath能够对应起来。但是，OGNL和XPath都各自是功能很强大的语言，复杂的用法并不能对应。