Velocity vs Xslt

Velocity vs Xslt

评估指标

下面列出一系列比较详细的、能够落到实处的、能够客观量化的、可操作的评估指标。评分采取 10 分作为满分。

(1) 模板纯净度

这主要是指 Template 里面没有 Script Logic 代码污染。

Velocity和Xslt都是采用自身语言与Html结合，所以在这个方面它们都是0分。

(2) 模板整洁度

主要是指 Template 的格式是否整齐规范。

XSLT 无疑是胜利者，本身就是 XML 格式，通用的 XML Parser 就可以解析它们，能够获得 10 分，Velocity只能获得 0 分。

(3) 替换灵活度

主要是指能否自由替换 Template 里面的任何一块文本。不用考虑 DOM Node 。

Velocity无疑是胜利者，毫无限制，能够获得 10 分

XSLT或多或少受到 DOM Node 的限制（解析的最小单位是 XML Node ），能够获得 6 分。

(4) 所见即所得

Template 能够在 Browser 里面直接大致正确显示，设计人员友好。

由于这两个都是都是采用标记语言，都是通过在HTML文件中加入标记来作为显示的内容，所以它不能在浏览器中显示友好内容。所以这一项都是0分。但Velocity 属于按行解析，有可能采取如下手段，把语句包含在 XML Comment 里面，进行显示友好的处理。这种情况下得分 5 。

(5) 用户代码纯净度

主要是指用户提供显示数据的后台 Java 代码的纯净度，是否免除了 HTML ，或者 Template 操作的污染。

Velocity 都能够获得 10 分。用户后台代码十分纯净，不需要引入具体框架的代码。任何一份 Action Code ，完全不用知道自己使用的是什么 Template 。而XSLT也能得到10分。

(6) 动态 Include

即运行的时候，动态选择 Include 另外的 Template 文件。

Velocity的 #Parse 指令应该也是动态解释执行的。也可以算是动态 Include 。XSLT能够动态引入并使用其他的 XSL 。所以， Velocity， XSLT 的动态 Include 方面的分数都是 10 。

(7) 树型数据的递归显示

递归显示一个任意深度的树型数据，这是一个动态 Include 基础上的更高级的需求。可以说，不支持动态 Include ，就不支持递归显示。

递归， XSLT 无疑是天生赢家。 XSLT 的 Pattern Match 语法可以说就是为递归编写的。对于 Velocity这类没头没尾的 Script 来说，属于强人所难。

所以，XSLT得10分，但Velocity也能显示特定的 Tree Model 。得分 4 。

(8) 空间效率

基于 Template Manipulation 的技术都有空间效率问题。用户同时访问同一个 Page 的时候，内存中存在多个副本。

XSLT，Velocity内存里的静态文本都只保存一份，都没有严重的空间效率问题，得分都是 10 。

(9) 映射关系明显度

什么数据应该显示在什么位置，一目了然。这种特性。

Velocity直接在 Template 里面把数据取出来显示，一目了然，清清楚楚，得分都是 10 。

XSLT 的 XPath Pattern Match 也是要稍微转个弯，得分为 5 。

(10) 显示逻辑重用度

嵌在 Template 里面的 Server Side Script 代码，不具有任何可重用性。除了整个 Include ，你无法在另外的地方调用Template 里面的某一段代码。

Velocity， XSLT 的逻辑可重用度分数都是 0 。当页面设计人员更改了具体页面布局元素（ HTML Tag ）的时候，原来的 Template 里面的 Script 全部作废，需要重新填充到新的 HTML 里面。

总结：

Velocity的优势在于这种技术对用户后台 Java 代码侵入性非常低，可以与其它 Template 可以任意替换，而不影响用户后台 Java 代码。另外，Velocity语法很少，简单易学。而XSLT的最大优势就在于能XML的超强处理。