为什么选择XSL转换？
对于当前项目，必须决定是使用XML和XSL转换来生成HTML还是直接使用HTML模板。
我对支持或反对XSL方法的论据感兴趣。 我知道，在你必须支持许多不同布局的情况下，XSL解决方案有很多优点，但是为什么在那些只需要支持一个目标布局的情况下你会选择它？
编辑：我们在这里谈论Java。
XSLT是一种函数式编程语言，您可以使用它来创建与任何模板系统一样丰富的前端。 但是，你不应该 – 你和你的团队会疯狂。
这两个选项都提供了以逻辑方式将对象转换为表示forms的机会。 XSLT最适合创建更多XML，这可能会让您相信它是用于创建XHTML的完美候选者。 但是，创建XHTML不应该是主要目标 – 创建用户体验是。 不要关心媒体 。
XSLT的两个显着缺点涉及语法：您的模板，它们包含的模板以及这些模板包含的模板都将是巨大而冗长的。 其次，你将不得不做很多函数式编程，当遇到带有累积函数参数的递归模板而不是简单的for循环时，经验不足的工程师可能会感到困惑和害怕。
如果您被改造逻辑构造的有效XML实体的美感所吸引，那么请考虑使用类型安全的模板系统来转换bean。 查看Google XML页面 ，创建逻辑组织的，类型安全的模板，以便将来的工程师轻松选择和扩展。
我大约5年前为企业产品创建了一个XML / XSLT驱动的UI。 我们仍在使用它，现在我可以回顾一下我的经验并看到许多利弊：
优点：
- XSL是一种function强大的声明性语言，对于经验丰富的开发人员来说非常有用和有趣，而且转换可以通过几行代码完成相当多的工作。
- XSL设计用于XML，因此如果您的数据已经是XML，那么它很有意义
- 关注点分离（渲染与数据）比许多模板语言更好
- 基于XSL的渲染可以很容易地“子类化”。 我的意思是：假设你有数据类A和关联模板A.xslt。 对于从A派生的B类，您可以轻松创建仅具有较小差异的B.xslt，并且包含用于inheritance行为的A.xslt。 由于A.xslt的变化，这使得它不易破碎。
- 上述观点也为您提供了覆盖的权力。 对于具有关联A.xslt的A类，我们可以轻松地将关联模板切换为A-custom.xslt，这是一些小的更改加上A.xslt的inheritance。 我们可以在现场动态执行此操作，再次，好处是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进行转换时会产生大量开销
- 根据变换器的function，当您转换为字符串缓冲区然后将该字符串发送到输出设备时，也可能会产生缓冲开销
- 您的XSLT使用越高级，您的工具支持您的可能性就越小（特别是当您开始使用包含或更快的方式传递XML数据时）
当我想到更多问题时，我会尝试更新。 我认为现在回过头来看，我的判决就是坚持使用通用的模板语言。 我选择XML / XSLT时曾经遇到的大问题现在已经被主要模板引擎的更新和更成熟的版本所解决。 我们仍然可以从inheritance.xslt文件的能力中获益，这是大多数模板引擎都做不好的事情。 但最终，许多开发人员提供示例的价值要大得多（例如，比较ASP.NET答案与StackOverflow上的XSLT答案。）
希望有所帮助！
我使用XSLT进行了重要的开发，并且它在两个不同的站点都取得了巨大的成功和完全的失败。
结论前的一些想法：
-
我认为没有人会认为XSLT比模板解析引擎更强大，它是一种function语言。
-
虽然它没有像大多数程序语言那样广泛采用，但它仍然是一种真正用于实际项目的语言，人们可以通过XSLT的知识获得雇佣，这对于您现有的员工来说是一种可转移的技能。
-
XSLT已经存在了一段时间，实现已经成熟，我确信这是长时间运行的模板引擎（如Velocity）的情况，但较新的引擎可能不那么健壮。
-
无论您决定使用哪种模板语言，它都不太可能像XSLT那样有详细记录。 查看迈克尔凯程序员的任何参考系列，了解如何制作出色的参考书。
-
工具支持通常非常好……如果您有预算。 XMLSpy和Stylus Studio在过去对我都非常有用。
-
XSLT不仅很难，更重要的是不同。 大多数人都不是正式接受过函数式编程培训的计算机科学gradle生。 大多数程序员都会以程序化的方式编写XSLT，这种方式不会利用语言的任何function并给您带来维护问题。
-
XSLT转换可能很慢并且可能占用大量内存。 如果您的样式表具有大型XML输入，则可能会出现问题。
我喜欢XSLT但是你是否应该使用XSLT归结为几点：
你是否致力于XSLT？ 您是否拥有XSLT的内部专业知识？ 你准备好了吗？
你的数据是用XML吗？ 它在XML中有意义吗？ 你是否有内部人员喜欢你的数据，以确保它的结构良好，总是有一个合适的架构？
除非这些问题的答案是肯定的并且您有复杂的数据需要复杂的渲染过程，否则我不会考虑使用XSLT ……尤其是如果团队中没有经验的话。 糟糕的XSLT比糟糕的模板更糟糕得多。
但是，它可以以可维护的方式呈现复杂的数据，这对于今天的许多模板引擎来说是不可能的。
采用XSL方式将使您的应用程序面向未来。 这意味着，如果您决定在将来添加更多具有不同布局的模板，您将能够充分利用这些优势。 在我当前的项目中，我们保存了所使用的XML（在XMLType或CLOB中）并允许其他应用程序访问数据和XSL模板以通过Web服务生成文档。 由于我们决定使用XML / XSL，因此我认为原始设计非常容易实现。
XSLT的优点是能够以其他文档类型（即pdf）生成输出，并且现在很可能使用pdf输出。 XML / XSLT还会从视图中分离数据。
当我们过去完成XSLT时，它允许扩展我们的产品。 输出保持不变，只需要更改表示层。 当我们有想要“自定义”UI的客户端时，这为我们提供了很大的灵活性，因为我们需要做的就是替换XSLT文件。 如果您预见到需要进行大量此类更改，XSLT可能就是您的答案。
但是，如上所述，XSLT语法和函数编程思路可能使得难以有效地生成模板。 我们发现，我们喜欢坚持我们学到的技巧，当我们的客户要求超出我们已经知道的范围时，没有人愿意为这张票做志愿者。 通常有人最终会想出如何完成这项任务，而且我们的“技巧包”变得越来越大，但找出新事物往往非常麻烦。
如果你没有预见到改变UI，或者至少没有改变，那么XSLT可能不值得付出额外的努力。
请不要将XML / XSLT用于Web前端。 我在这样的项目中，这太可怕了。 通常，您必须首先从对象或类似的东西生成XML，这是没有意义的。 第二点是，有很多优秀的HTML编辑器是免费的，但我没有找到XSLT。 所以编辑复杂的XSLT并不好玩。 我建议使用HTML模板和通用模板引擎。
根据您的应用程序，拥有一个XML层然后通过XSLT转换为XHTML也可以，您可以将简单的WebServices编写到XML层 – 允许您的客户使用您的站点数据…
将XML发送到具有转换链接的浏览器（忘记确切的语法…）也需要更少的带宽，因为XSLT文件将保持不变并且您只需要传递它构建的原始XML – 一种比如使用外部CSS样式表而不是将样式属性添加到标记中;）
我认为你需要检查数据来源是什么。 正如之前的boris callens所提到的，如果您要从数据库中提取数据，则必须首先转换为XML，然后应用转换。 如果数据源是RSS等，那么XSLT是一个自然的选择。
XPATH和XSLT具有很高的学习曲线，function编程可能令人望而生畏。 在时间紧缩中，这可能不是正确的选择。
对于前端工作，JSON具有较轻的有效负载，并且很容易受到jQuery和其他Javascript库的支持。 您可能希望将JSON视为数据协议，因为jQuery库对开发人员来说更容易访问，并且使用框架提高工作效率的时间远远少于使用XSLT，标记中嵌入的Javascript，可怕的语法以及随附的所有其他细节。前端有XML / XPATH / XSLT。
把事情简单化。 这是一个人越来越欣赏的原则。
Velocity或Freemarker非常灵活且function多样。 您的代码库将清晰，易于理解，并且它将比X怪物运行得更快（更快）。
如果您的数据已经是XML，我会看到XSL方法如何方便。
但通常情况并非如此。 它位于数据库中的某个位置，需要在现场生成或来自某些服务。
从这个源创建XML然后能够从该XML创建HTML在我看来是没用的。 我会坚持使用（X）Html模板。
与HTML相比，如果您需要以任何方式解析和处理模板，那么可以使用许多XML工具。 因此，您应该选择XML以获得使用XML工具和库的好处。
但是，也就是说，XHTML可能只是满足您的需求，因为这样可以完全支持XML工具和库，同时仍然是现代Web浏览器正确处理的普通HTML。 如果您稍后需要对这些进行后处理，您仍然可以将XSLT应用于XHTML数据。
我在以前的项目，金融网站中使用过XML和XSLT，它对我们很有用，但是：
- 我们有多个客户，这改变了我们的产出数量。 我们可以替换XSLT样式表，这使得对开发人员更容易管理的站点更改
- 我们团队中有一位专业的网络编辑。 我们给了他们示例XML，他们可以直接编辑样式表
- 如果昨天有任何需要进入网站的措辞变化（这是一家银行，这经常出人意料地经常发生），我们可以部署新的XSLT而无需重新部署整个网站。
- 需要多种不同的输出格式。 我们使用FOP转换为PDF，这是基于相同的技术，所以我们不太难理解:-)
我看到使用XSLT的主要原因是，如果您有多个站点都基于相同的XML，但需要不同的HTML输出。
XML + XSLT非常酷。 您可以在将来输出多种类型的目标格式。 但是他知道XML中的嵌入式HTML。 Firefox XSLT不支持“disable-output-escaping”。 见Bugzilla 。
我们使用XSLT在我们的内容管理系统中生成html，它运行得很好。
一些提示：不要试图从一个大毛茸茸的XML一次生成所有页面，你会疯了。 使用带有嵌入标记的HTML模板（带有样式，装饰和基本标记的纯文本/ html文件）（例如，<！ - MENU - >，<！ - CONTENT - >），并使用xslt-transformation替换标记适当的数据。
话虽如此，我怀疑你真的需要xslt，如果你只有一个布局，永远。