XSLT 值得吗？ [关闭]答案

【问题标题】：Is XSLT worth it? [closed]XSLT 值得吗？ [关闭]
【发布时间】：2010-09-09 20:57:39
【问题描述】：

不久前，我开始了一个项目，在该项目中我设计了一个 html 风格的 XML 模式，以便作者可以以简化的格式编写他们的内容（教育课程材料），然后通过 XSLT 将其转换为 HTML。我玩了（苦苦挣扎）了一段时间，并把它弄到了一个非常基本的水平，但后来对我遇到的限制（这很可能是我知识的限制）太恼火了，当我读到一篇建议放弃的博客时XSLT 并且只需使用您选择的语言编写您自己的 XML 到任何解析器，我急切地跳到了它上面，结果非常出色。

直到今天我仍在努力（实际上我应该现在就在努力，而不是玩 SO），而且我看到越来越多的东西让我觉得放弃 XSLT 的决定是一个好决定。

我知道 XSLT 有它的位置，因为它是一个公认的标准，而且如果每个人都编写自己的解释器，90% 的人最终会使用TheDailyWTF。但鉴于它是functional style language，而不是大多数程序员熟悉的程序风格，对于像我这样从事项目的人来说，你会建议他们走我做过的路，还是坚持下去退出 XSLT？

【问题讨论】：

我认为您的问题主题（这是有争议的）与您提出的实际问题（即 SO 读者是否实际使用 XSLT，或推荐使用它）之间存在严重脱节。也不清楚为什么您需要回答这个问题。
@Martin，你会建议什么标题？我不需要回答这个问题，但我认为这很有趣，并且对于试图决定是否投资 XSLT 或替代方案的人也很有用。
我认为 XSLT 已经在炒作周期内达到了生产力的高原 (en.wikipedia.org/wiki/Hype_cycle)。
我个人觉得我的 XML 在经过至少 1 或 2 次转换之前不会增加任何价值。
@Martinv.Löwis，同意您的评估。此外，这实际上归结为企业问题，这意味着如果同一个人完成所有操作，并且方法是启动.... 很好，以最快的实施方式完成它，无论如何，您只会在这种情况下搞砸自己。 XSLT 在点击之前是相当困难的，需要特定领域的知识，但是在一个大型组织中......我的上帝，你意识到所有反 XML 的人都是多么的错误。而且，一旦您了解 XSLT，它就是最好的选择，只有当您不了解 XSLT 时才会出现这种情况，因此您要考虑学习投资。

标签： html xml xslt xml-parsing

【解决方案1】：

这取决于您需要它。它的主要优势是转换的易于维护性，编写自己的解析器通常会消除这一点。话虽如此，有时系统又小又简单，真的不需要“花哨”的解决方案。只要您的基于代码的构建器是可替换的，而无需更改其他代码，没什么大不了的。

至于 XSL 的丑陋，是的，它很丑陋。是的，这需要一些时间来适应。但是一旦你掌握了它（不应该花很长时间IMO），它实际上是一帆风顺的。根据我的经验，编译后的转换运行得非常快，您当然可以对其进行调试。

【讨论】：

【解决方案2】：

XSLT 的优点：

特定于 XML 的域，因此不需要在输出中引用文字 XML。
支持 XPath/XQuery，这是查询 DOM 的好方法，就像正则表达式是查询字符串的好方法一样。
函数式语言。

XSLT 的缺点：

可能过于冗长 - 您不必引用文字 XML，这实际上意味着您必须引用代码。而且不是很漂亮。但话又说回来，它并不比典型的 SSI 差多少。
不做大多数程序员认为理所当然的事情。例如，字符串操作可能是一件苦差事。当新手设计代码时，这可能会导致“不幸的时刻”，然后疯狂地在网络上搜索如何实现他们认为会出现的功能的提示，而没有给自己时间编写。
函数式语言。

顺便说一句，获得程序行为的一种方法是将多个变换链接在一起。在每个步骤之后，您都有一个全新的 DOM 可以处理，它反映了该步骤中的更改。一些 XSL 处理器具有扩展，可以在一次转换中有效地执行此操作，但我忘记了细节。

因此，如果您的代码主要是输出而没有太多逻辑，那么 XSLT 可以是一种非常简洁的表达方式。如果有很多逻辑，但主要是内置于 XSLT 的表单（选择所有看起来像 blah 的元素，并为每个元素输出 blah），那么它可能是一个非常友好的环境。如果您喜欢始终像 XML 一样思考，那么试试 XSLT 2。

否则，我会说，如果您最喜欢的编程语言具有良好的 DOM 实现，支持 XPath 并允许您以有用的方式构建文档，那么使用 XSLT 几乎没有什么好处。与 libxml2 和 gdome2 的绑定应该做得很好，坚持使用您熟悉的通用语言并不丢人。

自制的 XML 解析器通常不是不完整的（在这种情况下，您总有一天会遇到困难），或者不比现成的东西小很多（在这种情况下，您可能会浪费时间），并让您有机会围绕恶意输入引入严重的安全问题。除非您确切地知道这样做会获得什么，否则不要写。这并不是说如果您不需要 XML 提供的所有内容，就不能为比 XML 更简单的输入格式编写解析器。

【讨论】：

XSLT 不起作用，它是声明性的（如 SQL）。
在我看来，一个 XSL 模板具有纯函数的所有标准，是什么使它不符合被描述为函数的资格？为什么“声明式”是一种替代方案？ a = 1;是声明性的。
它像 Prolog 一样是声明性的。 en.wikipedia.org/wiki/Declarative_programming
我相信函数式编程是一种声明式编程。
虽然关于 XSLT 2.0 的观点很好，但在我撰写本文时，还没有广泛支持 XSLT 2.0。

【解决方案3】：

我认为你做对了。根据我的经验，XSLT 开发人员是最难招聘的，因为它是一门从未受到 Web 开发人员和普通程序员欢迎的语言。

因此，您最终不得不为“了解主流语言之外的语言的高级程序员”付费，但要购买一种可能不是该程序员最喜欢的语言。

【讨论】：

【解决方案4】：

我发现 XSLT 很难使用。

我曾在与您描述的系统有些相似的系统上工作过。我的公司注意到我们从“中间层”返回的数据是 XML 格式的，并且页面将以 HTML 格式呈现，这也可能是 XHTML，而且他们听说 XSL 是在 XML 之间进行转换的标准格式。所以“架构师”（我指的是那些深思熟虑但显然从不编码的人）决定我们的前端将通过编写将数据转换为 XHTML 以显示的 XSLT 脚本来实现。

结果证明这个选择是灾难性的。事实证明，XSLT 编写起来很痛苦。因此，我们所有的页面都难以编写和维护。如果使用 JSP（这是在 Java 中）或使用一种标记（尖括号）作为输出格式（HTML）和另一种标记（如 ) 用于元数据。 XSLT 最令人困惑的地方在于它是用 XML 编写的，并且它可以从 XML 转换为 XML……很难将所有 3 个不同的 XML 文档都牢记在心。

您的情况略有不同：不像我那样在 XSLT 中编写每个页面，您只需在 XSLT 中编写一点代码（从模板转换为显示的代码）。但听起来你可能遇到了和我一样的困难。我想说，尝试像您那样解释简单的基于 XML 的 DSL（领域特定语言）并不是 XSLT 的强项之一。（虽然它可以完成这项工作......毕竟它是图灵完备的！）

但是，如果您所拥有的更简单：您拥有一种 XML 格式的数据，并且想要对其进行简单的更改——不是完整的页面描述 DSL，而是一些简单直接的修改，那么 XSLT 是一个出色的工具那个目的。它的声明性（而非程序性）性质实际上是为此目的的优势。

-- 迈克尔·彻姆赛德

【讨论】：

【解决方案5】：

我为我的公司维护一个在线文档系统。作者使用 SGML（类似 xml 的语言）创建文档。然后将 SGML 与 XSLT 组合并转换为 HTML。

这使我们无需进行任何编码即可轻松更改文档布局。只需更改 XSLT。

这对我们很有效。在我们的例子中，它是一个只读文档。用户没有与文档进行交互。

此外，通过使用 XSLT，您可以更接近您的问题域 (HTML)。我一直认为这是个好主意。

最后，如果您当前的系统工作正常，请不要管它。我绝不会建议破坏您现有的代码。如果我从头开始，我会使用 XSLT，但在你的情况下，我会使用你所拥有的。

【讨论】：

【解决方案6】：

我喜欢使用 XSLT 来改变 XML 文档的树结构。我发现做任何与文本处理相关的事情并将其委托给我可能在将 XSLT 应用于 XML 文档之前或之后运行的自定义脚本都很麻烦。

XSLT 2.0 包含了更多的字符串函数，但我认为它不太适合该语言，并且 XSLT 2.0 的实现并不多。

【讨论】：

【解决方案7】：

我记得当 XSLT 标准刚刚发布时，所有关于 XSLT 的炒作。能够通过“简单”转换构建完整的 HTML UI 令人兴奋。

让我们面对现实吧，它很难使用，几乎无法调试，而且速度通常非常慢。最终的结果几乎总是古怪的，不太理想。

我宁愿自食其力，也不愿使用 XSLT，因为有更好的方法来做事。它仍然有它的位置，它适用于简单的转换任务。

【讨论】：

慢得难以忍受？？跟什么比较？
与我在VB6中手写转换相比。比 XSLT 快几个数量级（我正在将 ADO 记录集转换为 HTML - 早在 2002 年之类的 :-)
使用 Oxygen 等工具进行调试比您想象的要容易得多。

【解决方案8】：

我在 XSLT 上花费了很多时间，发现虽然它在某些情况下是一个有用的工具，但它绝对不能解决所有问题。当它用于机器可读 XML 输入/输出的数据转换时，它非常适合 B2B 目的。我认为您在声明其局限性时没有走错路。最让我沮丧的事情之一是 XSLT 实现中的细微差别。

也许您应该看看其他一些可用的标记语言。我相信 Jeff 写过一篇关于 Stack Overflow 的文章。

Is HTML a Humane Markup Language?

我会看看他写了什么。您可能会找到一个“开箱即用”的软件包，或者至少非常接近，而不是从头开始编写自己的东西。

【讨论】：

【解决方案9】：

XSLT 并不是 xml 转换的终极目标。但是，根据给出的信息很难判断它是否是解决您的问题的最佳解决方案，或者是否有其他更有效和可维护的方法。您说作者可以以简化格式输入他们的内容——什么格式？文本框？你把它转换成什么样的html？要判断 XSLT 是否是适合这项工作的工具，有助于更详细地了解这种转换的特征。

【讨论】：

作者在文本编辑器中编写 XML。基本上它是一个简化的 HTML - 一些东西已经被移除以强制一致的样式，像标签这样的东西已经被添加为更复杂的 HTML 的简写。其他元素用于生成菜单/参考书目/词汇表等。

【解决方案10】：

XSLT specification 将 XSLT 定义为“一种将 XML 文档转换为其他 XML 文档的语言”。如果您尝试在 XSLT 中进行最基本的数据处理以外的任何事情，那么可能有更好的解决方案。

另外值得注意的是，XSLT 的数据处理能力可以在 .NET 中使用自定义扩展函数进行扩展：

【讨论】：

用非标准扩展扩展标准语言是最糟糕的事情。你最终得到的既不是 XSLT 也不是 CLR 代码。
公平，但这并不意味着它有时没用

【解决方案11】：

就我个人而言，我在完全不同的环境中使用 XSLT。我当时正在开发的电脑游戏使用了大量使用 XML 定义的 UI 页面。在发布后不久的一次重大重构中，我们想要更改这些 XML 文档的结构。我们使游戏的输入格式遵循更好的架构感知结构。

XSLT 似乎是从旧格式 -> 新格式转换的完美选择。在两周内，我完成了数百页从旧到新的有效转换。我还能够使用它来提取有关我们 UI 页面布局的大量信息。我创建了相对容易地嵌入了哪些组件的列表，然后我使用 XSLT 将其写入我们的架构定义中。

此外，来自 C++ 背景，这是一门非常有趣且值得掌握的语言。

我认为作为一种将 XML 从一种格式转换为另一种格式的工具，它非常棒。但是，它不是定义以 XML 作为输入并输出 Something 的算法的唯一方法。如果您的算法足够复杂，则输入是 XML 的事实与您选择的工具无关 - 即在 C++ / Python / 中使用您自己的工具。

具体到您的示例，我想最好的想法是创建您自己的 XML->XML 转换，以遵循您的业务逻辑。接下来，编写一个 XSLT 翻译器，它只知道格式化并且什么都不做。这可能是一个很好的中间立场，但这完全取决于你在做什么。在输出上安装 XSLT 转换器可以更轻松地创建替代输出格式 - 可打印、用于移动设备等。

【讨论】：