为什么选择XSL转换？

Question

对于当前项目,必须决定是使用XML和XSL转换来生成HTML还是直接使用HTML模板.

我对支持或反对XSL方法的论据感兴趣.我知道,在你必须支持许多不同布局的情况下,XSL解决方案有很多优点,但为什么在那些只需支持一个目标布局的情况下你会选择它？

编辑:我们在这里谈论Java.

Answer 1

XSLT是一种函数式编程语言,您可以使用它来创建与任何模板系统一样丰富的前端.但是,你不应该 - 你和你的团队会疯狂.

这两个选项都提供了以逻辑方式将对象转换为表示形式的机会.XSLT最适合创建更多XML,这可能会让您相信它是用于创建XHTML的完美候选者.但是,创建XHTML不应该是主要目标 - 创建用户体验是.不要关心媒体.

XSLT的两个显着缺点涉及语法:您的模板及其包含的模板以及这些模板包含的模板都将是巨大而冗长的.其次,你将不得不做很多函数式编程,当遇到带有累积函数参数的递归模板而不是简单的for循环时,经验不足的工程师可能会感到困惑和害怕.

如果您被改造逻辑构造的有效XML实体的美感所吸引,那么请考虑使用类型安全的模板系统来转换bean.查看Google XML页面,创建逻辑组织的,类型安全的模板,以便将来的工程师轻松选择和扩展.

Answer 2

我大约5年前为企业产品创建了一个XML/XSLT驱动的UI.我们仍在使用它,现在我可以回顾一下我的经验并看到许多利弊:

优点:

• XSL是一种功能强大的声明性语言,对于经验丰富的开发人员来说非常有用和有趣,而且转换可以通过几行代码完成相当多的工作.
• XSL设计用于XML,因此如果您的数据已经是XML,那么它很有意义
• 关注点分离(渲染与数据)比许多模板语言更好
• 基于XSL的渲染可以很容易地"子类化".我的意思是:假设你有数据类A和相关的模板A.xslt.对于从A派生的B类,您可以轻松创建仅具有较小差异的B.xslt,并且包含用于继承行为的A.xslt.由于A.xslt的变化,这使得它不易破碎.
• 上述观点也为您提供了覆盖的能力.对于具有关联A.xslt的A类,我们可以轻松地将关联模板切换为A-custom.xslt,这是一些小的更改加上A.xslt的继承.我们可以在现场动态执行此操作,再次,好处是A-custom.xslt只有几行,而不是原始A.xslt的整个修改副本.占地面积小意味着它更有可能使用多个版本的A.xslt.
• 在.NET 2.0中,XSLT被编译并变得非常快.Java可能有类似的技术.(大多数模板语言现在都这样做.)
• 在.NET中,可以创建"Object XPath Navigator",它允许您转换数据对象,而无需将它们转换为XML对象.Java中也可能有类似的技术
• XSLT非常了解HTML并处理转义,空白问题等问题

缺点:

• XSL是一种强大的声明性语言,让新程序员感到困惑 - 很少有人了解XSLT
• XSL很冗长.XML通常也很冗长.
• XSL转换可能比"本机"模板慢.即使在编译时,XSL的状态开销仍比大多数模板语言多
• 将参数传递给XSL很困难,您必须将它们与您的数据一起发送(强制您创建额外的XML)或通过特定于系统的方法(也可能涉及构建XML数据)
• 如果您没有ObjectXPathNavigator或等效项,那么在将数据对象转换为XML进行转换时会产生大量开销
• 根据变换器的功能,当您转换为字符串缓冲区然后将该字符串发送到输出设备时,您可能还会产生缓冲开销
• 您的XSLT使用越高级,您的工具支持您的可能性就越小(特别是当您开始使用包含或更快的方式传递XML数据时)

当我想到更多问题时,我会尝试更新.我认为现在回顾一下,我的判断是坚持使用通用的模板语言.我选择XML/XSLT时曾经遇到的大问题现在已经被主要模板引擎的更新和更成熟的版本所解决.我们仍然可以从继承.xslt文件的能力中获益,这是大多数模板引擎都做不好的事情.但最终,许多开发人员提供示例的价值要大得多(例如,比较ASP.NET答案与StackOverflow上的XSLT答案.)

希望有所帮助!

Answer 3

我使用XSLT进行了重要的开发,它在两个不同的站点都取得了巨大的成功和完全的失败.

结论前的一些想法:

• 我认为没有人会认为XSLT比模板解析引擎更强大,它是一种功能语言.

• 虽然它没有像大多数程序语言那样被广泛采用,但它仍然是一种真正用于实际项目的语言,人们可以通过XSLT知识获得聘用,这对于您现有的员工来说是一种可转移的技能.

• XSLT已经存在了一段时间,实现已经成熟,我确信这是长时间运行的模板引擎(如Velocity)的情况,但较新的引擎可能不那么健壮.

• 无论您决定使用哪种模板语言,它都不太可能像XSLT那样有详细记录.查看Michael Kay Programmer的任何参考系列,了解如何制作出色的参考书.

• 工具支持通常非常好......如果您有预算.XMLSpy和Stylus Studio过去对我都非常有用.

• XSLT不仅很难,更重要的是不同.大多数人都不是正式接受过函数式编程培训的计算机科学毕业生.大多数程序员都会以程序化的方式编写XSLT,这种方式不会利用语言的任何功能并给您带来维护问题.

• XSLT转换可能很慢并且可能占用大量内存.如果您的样式表具有大型XML输入,则可能会出现问题.

我喜欢XSLT但是你是否应该使用它归结为几点:

你是否致力于XSLT？您是否拥有XSLT的内部专业知识？你准备好了吗？

你的数据是用XML吗？它在XML中有意义吗？你是否有内部人员喜欢你的数据足以确保它的结构良好并且总是有适当的架构？

除非这些问题的答案是肯定的并且您有复杂的数据需要复杂的渲染过程,否则我不会考虑使用XSLT ...尤其是如果团队中没有经验的话.糟糕的XSLT比糟糕的模板更糟糕得多.

但是,它可以以可维护的方式呈现复杂的数据,这对于今天的许多模板引擎来说是不可能的.

Answer 4

采用XSL方式将使您的应用程序面向未来.这意味着,如果您决定在将来添加更多具有不同布局的模板,您将能够充分利用这些优势.在我当前的项目中,我们保存了所使用的XML(在XMLType或CLOB中)并允许其他应用程序访问数据和XSL模板以通过Web服务生成文档.由于我们决定使用XML/XSL,因此我认为原始设计非常容易实现.