canonical

     adun今天问我xslt到底有什么用。相对于其他技术，它有什么存在的必要性。
    xslt的主要作用是对xml结构的转换，即它是一种描述结构变换规则的语言。不过也可以将它与我们更熟悉的用于生成html(结构)的模板语言作一个对比。
1. 两者都能直接生成xml格式的文本（结构）
2. 两者都有循环和判断等逻辑处理语句。
3. 模板语言可以通过EL表达式等语言取得源数据, xslt通过xpath语法取得源数据.
4. 模板语言通过自定义tag等机制实现分解和组合, xslt通过xsl:call-template等语法实现分解与组合.

     tpl等模板语言直接操纵java中的对象, 体现的是图(Graph)模型, 并通过对象函数封装了部分动态性. 一般访问的时候是通过短程关系逐级访问,例如x.y.funcA().b。利用apache项目组的jxpath包，我们也可以使用类似于xpath的语 法在对象图上进行全局访问。
    xslt使用严格定义的xpath语法访问Tree结构，具有很强的数据操纵能力，例如我们可以通过//mynode等语法轻易的实现节点的聚合，构造出 新的结构。在一般xslt包的实现中，都提供了javascript扩展，可以使用javascript构造出的数据节点。

     在tpl这样的模板语言中java中的数据对象结构与tpl中的模板结构（处理规则的结构）是两分的，而在xslt中输入数据结构与xslt自身处理规则 的机构却是统一的。实际上tpl这样的模板语言主要是基于过程语义，即先做。。。，用到。。。，然后。。。, 而xslt对于输入数据的结构具有明确的全局性假设，主要是一种转换语义，即不论在什么情况下，只要遇到。。。，就做。。。。 在xslt中可以通过xpath语法指定处理规则针对数据（输入结构）的的触发条件, 而在tpl中只能通过＜c:decorator＞为tpl标签指定转换器，而无法针对数据指定处理规则。

     在数据访问模型这一方面，原则上说xslt与模板语言各有优势。实际在用于html生成的过程中，xpath的全局访问和匹配能力一般难以得到发挥，而 xml格式的限制又在一定程度上阻碍了使用灵活的数据供体，这方面模板语言有一定的优势。但是xslt的约束更强也有本质性的好处，它使用xml数据并输 出xml数据，维护了结构的同质性，便于管道操作。因为假设更明确，xslt对于xml格式的数据的操纵和封装能力也要强于模板语言。例如它可以使用来为 节点追加属性。

     xslt在用于xhtml生成时的一个主要劣势在于它是对变换规则的分解之后的描述，而我们所希望得到的是最终的结果，即这些规则综合应用所生成的结果。 虽然xslt的语法是xml语言，与xhtml在语法格式上保持了一致性。但是在xslt中，xslt的标签破坏了xhtml语义上的结构，使得目前无法 做到所见即所得。我们不得不在头脑中运行xslt规则来想象最终的结果，这无疑是痛苦的。模板语言在这方面要轻松许多。

     xslt的另一个问题是有时xml语法显得过于冗长了。在操纵一些局部结构的时候，xml节点并不一定是合适的表达。例如

＜xsl:value-of select="$x"/＞ 对比 ${x},

＜xsl:call-template name="subrule"＞
    ＜xsl:with-param name="argA"＞＜xsl:value-of select="substring-after($path,'.')"/＞＜/xsl:with-param＞
＜/xsl:call-template＞
对比
＜my:subrule argA="${path.substringAfter('.')}" /＞

在调用子模板方面，显然xslt封装的抽象层次也要弱于tpl模板语言。

     xslt作为一种xml格式的结构变换语言，维护了xml世界的概念完整性，其意义无疑是重大的。但并不是所有时候xml都是最适的描述模型。我们最好还 是将它与其他技术结合使用。目前在witrx平台中，我们对于xslt的使用主要是对tpl模板进行布局和过滤处理，即xslt用于对处理规则进行变换， 而将根据数据生成html这个最细致的工作留给过程处理能力和封装能力更强的tpl模板语言。