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