adun今天问我xslt到底有什么用。相对于其他技术,它有什么存在的必要性。 tpl等模板语言直接操纵java中的对象, 体现的是图(Graph)模型, 并通过对象函数封装了部分动态性. 一般访问的时候是通过短程关系逐级访问,例如x.y.funcA().b。利用apache项目组的jxpath包,我们也可以使用类似于xpath的语法在对象图上进行全局访问。 在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},
在调用子模板方面,显然xslt封装的抽象层次也要弱于tpl模板语言。
|
|