Question

不久前，我开始创建一个项目，我设计了一个html-esque XML模式，以便作者可以用简化的格式编写他们的内容（教育课程材料），然后通过XSLT将其转换为HTML。我玩了一段时间（挣扎）了一段时间并把它带到了一个非常基本的水平，但后来因为我遇到的限制（这可能是我的知识的局限性）太烦恼了，当我读到一篇建议要沟通的博客时XSLT只是用你选择的语言编写你自己的XML-to-whatever解析器，我急切地想到它并且它的工作非常出色。

到目前为止我还在努力（我现在应该正在努力，而不是在SO 上玩），我看到越来越多的东西让我觉得放弃XSLT的决定很好。

我知道XSLT有它的位置，因为它是一个公认的标准，并且如果每个人都在编写自己的解释器，其中90％将最终在TheDailyWTF。但是考虑到它是functional style language而不是大多数程序员熟悉的程序风格，对于那些开始像我自己这样的项目的人来说，你会建议他们沿着我做的路走下去，或者坚持使用XSLT ？

Answer 1

这么多的消极性！

我已经使用XSLT好几年了，真的很喜欢它。你需要意识到的关键是它不是一种编程语言，它是一种模板化的语言（在这方面我发现它无可比拟地优于asp.net / spit）。

XML是当今Web开发的事实上的数据格式，无论是配置文件，原始数据还是内存代表。 XSLT和XPath为您提供了一种非常强大且非常有效的方法，可以将数据转换为您可能喜欢的任何输出格式，立即为您提供将表示与数据分离的MVC方面。

然后是实用程序功能：清除命名空间，识别不同的模式定义，合并文档。

必须更好地处理XSLT而不是开发自己的内部方法。至少XSLT是一个标准，你可以雇用的东西，如果它对你的团队来说真的是一个问题，它的本质就是让你的大部分团队只使用XML。

真实世界的用例：我刚刚编写了一个应用程序，它在整个系统中处理内存中的XML文档，并根据最终用户的请求转换为JSON，HTML或XML。我有一个相当随机的请求提供Excel数据。一位前同事以编程方式做了类似的事情，但它需要一些类文件的模块，并且服务器安装了MS Office！原来Excel有一个XSD：新功能，3小时内基本码影响最小。

就我个人而言，我认为这是我职业生涯中遇到的最干净的事情之一，而且我相信所有明显的问题（调试，字符串操作，编程结构）都归结为对该工具的错误理解。

显然，我坚信这是“值得的”。

Answer 2

XSLT的优点：

特定于域的XML，因此例如无需在输出中引用文字XML。
支持XPath / XQuery，这可以是查询DOM的好方法，就像正则表达式可以很好地查询字符串一样。
功能语言。

XSLT的缺点：

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

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

因此，如果您的代码主要是输出而且逻辑不多，那么XSLT可以是表达它的非常简洁的方式。如果有很多逻辑，但主要是内置于XSLT的形式（选择所有看起来像blah的元素，并且每个输出都是blah），它可能是一个非常友好的环境。如果您一直想着XML-ishly，那么请给XSLT 2一个。

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

自行开发的XML解析器通常都是不完整的（在这种情况下，你有一天会被取消），或者比你可以下架的东西小得多（在这种情况下，你可能会浪费你的时间），并为您提供任何围绕恶意输入引入严重安全问题的机会。除非你确切地知道你获得了什么，否则不要写一个。如果您不需要XML提供的所有内容，那么并不是说您不能为XML比输入格式更简单地编写解析器。

Answer 3

我必须承认这里的偏见，因为我教XSLT为生。但是，可能值得覆盖我看到我的学生工作的领域。他们通常分为三组：出版，银行和网络。

到目前为止，许多答案可归纳为“对创建网站没有好处”或“它与语言X无关”。许多技术人员经历了他们的职业生涯，没有接触过功能/声明性语言。当我在教学时，经验丰富的Java / VB / C / etc民间是那些有语言问题的人（变量是代数意义上的变量，而不是程序编程的变量）。这是很多人在这里回答 - 我从来没有使用Java，但我不会因此而费心去批评这种语言。

在许多情况下，它是一种不适合创建网站的工具 - 通用编程语言可能更好。我经常需要获取非常大的XML文档并将它们呈现在Web上; XSLT使这一点变得微不足道。我在这个空间看到的学生倾向于处理数据集并在网上展示。 XSLT当然不是这个领域唯一适用的工具。但是，他们中的许多人都使用DOM来做这件事，而XSLT肯定不那么痛苦。

我看到的银行学生一般使用DataPower盒子。这是一个XML设备，它用于服务“说”不同的XML方言。在XSLT中，从一种XML语言到另一种XML语言的转换几乎是微不足道的，参加我的课程的学生人数正在增加。

我看到的最后一批学生来自出版背景（像我一样）。这些人倾向于拥有XML中的大量文档（相信我，作为一个行业正在发布的XML正在发布 - 技术出版已存在多年，贸易出版现在已经到了那里）。这些文档需要处理（这里会想到DocBook到ePub）。

上述人士评论说，脚本往往低于60行或者它们变得笨拙。如果它确实变得笨拙，那么编码器就没有真正理解的可能性 - XSLT与许多其他语言的思维方式截然不同。如果你没有心态，它就行不通。

这当然不是一种垂死的语言（我得到的工作量告诉我）。现在，它有点“卡住”，直到微软完成他们（很晚）的XSLT 2的实现。但它仍然存在，从我的观点来看似乎变得强大。

Answer 4

我们广泛使用XSLT来处理文档，并使一些复杂的配置设置可由用户使用。

对于文档，我们使用了很多DocBook，这是一种基于XML的格式。这使我们可以使用所有源代码存储和管理我们的文档，因为文件是纯文本。使用XSLT，我们可以轻松构建自己的文档格式，允许我们以通用方式自动生成内容，并使内容更具可读性。例如，当我们发布发行说明时，我们可以创建类似于：

的XML

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

然后使用XSLT（将上述内容转换为DocBook）我们最终得到了很好的发行说明（通常是PDF或HTML），其中错误ID自动链接到我们的错误跟踪器，错误按组件分组，以及所有内容的格式完全一致。并且可以通过查询我们的错误跟踪器来自动生成上述XML，以了解版本之间的变化。

我们发现XSLT有用的另一个地方实际上是我们的核心产品。有时，当与第三方系统连接时，我们需要以某种方式处理复杂HTML页面中的数据。解析HTML很难看，所以我们通过类似TagSoup（生成正确的SAX XML事件，基本上让我们处理HTML就好像它是正确编写的XML）来提供数据然后我们可以对它运行一些XSLT ，将数据转换为我们可以实际使用的“已知稳定”格式。通过将转换分离为XSLT文件，这意味着如果HTML格式发生更改，则不需要升级应用程序本身，而是最终用户可以自己编辑XSLT文件，或者我们可以通过电子邮件发送它们是一个更新的XSLT文件，不需要升级整个系统。

我想说，对于Web项目，今天有比处理XSLT更好的方法来处理视图，但作为一种技术，XSLT肯定有用。它不是世界上最容易使用的语言，但它绝对没有死，而且从我的角度来看仍然有很多好的用途。

Answer 5

XSLT是declarative programming语言的一个示例。

声明性编程语言的其他示例包括正则表达式，Prolog和SQL。所有这些都具有高度的表现力和紧凑性，通常设计精良，功能强大，适用于设计任务。

然而，软件开发人员通常讨厌这些语言，因为它们与更主流的OO或程序语言有很大不同，因此很难学习和调试。它们的紧凑性通常使得很容易在不经意间造成大量伤害。

因此，虽然XSLT是一种将数据合并到表示中的有效机制，但它在易用部门中失败了。我相信这就是为什么它没有真正流行起来。

Answer 6

我记得当标准新发布时围绕XSLT的所有宣传。所有令人兴奋的是能够使用“简单”转换构建整个HTML UI。

让我们面对它，它很难使用，几乎不可能调试，通常无法忍受的缓慢。最终结果几乎总是古怪而且不太理想。

我会更快地啃掉自己的腿，而不是使用XSLT，而有更好的方法可以做。它仍然有它的位置，它有利于简单的转换任务。

Answer 7

我已经广泛使用了XSLT（以及XQuery）用于各种事情 - 在构建过程中生成C ++代码，从doc注释生成文档，以及在必须使用XML和XHTML的应用程序中生成文档特别是很多。特别是代码生成器超过10,000行的XSLT 2.0代码遍布十几个单独的文件（它做了很多事情 - 客户端的头文件，远程代理/存根，COM包装器，.NET包装器，ORM - 来命名一些）。我继承了另一个不太懂语言的家伙，而旧版本因此非常混乱。我们写的新内容大多保持理智和可读，但我不记得实现这一点的任何特殊问题。对于C ++来说，当然没有比这更难的了。

说到版本，处理XSLT 2.0肯定有助于保持理智，但1.0对于更简单的转换仍然没有问题。在它的利基市场，它是一个非常方便的工具，你从某些特定领域的功能（最重要的是，通过模板匹配动态调度）获得的生产力很难匹配。尽管XSLT基于XML的语法被认为是单一的，但LINQ to XML（即使在带有XML文字的VB中）的相同之处通常要长几倍。然而，很多时候，由于在某些情况下不必要地使用XML，它会得到不应有的瑕疵。

总结一下：它是一个非常有用的工具，可以放在一个工具箱中，但它是一个非常专业的工具箱，所以只要你正确使用它并达到其预期目的，它就是好的。我真的希望有一个适当的，原生的.NET XSLT 2.0实现。

Answer 8

我使用XSLT（缺少更好的替代方案），但不用于演示，仅用于转换：

我编写简短的XSLT转换来对我们的maven pom.xml文件进行批量编辑。
我编写了一个转换管道，用于从XMI（UML Diagram）生成XML Schema。它工作了一段时间，但它最终变得太复杂了，我们不得不把它从谷仓后面拿出来。
我使用转换来重构XML Schemas。
我已经解决了XSLT中的一些限制，通过使用它来生成XSLT来完成实际工作。（曾经尝试编写一个使用命名空间生成输出的XSLT，这些命名空间直到运行时才知道吗？）

我一直回到它，因为它比我尝试过的其他方法更好地绕过它处理的XML，这些方法似乎不必要地有损或者只是误解了XML。 XSLT令人不快，但我发现使用Oxygen使它变得可以忍受。

那就是说，我正在调查使用Clojure（一个lisp）来执行XML的转换，但我还没有充分了解这种方法是否会给我带来好处。

Answer 9

我个人在完全不同的环境中使用XSLT。我当时正在处理的计算机游戏使用了大量使用XML定义的UI页面。在发布后不久的主要重构期间，我们想要更改这些XML文档的结构。我们使游戏的输入格式遵循更好的模式感知结构。

XSLT似乎是旧格式翻译的完美选择 - ＆gt;新格式。在两周之内，我有数百页从旧到新的转换。我还能够使用它来提取有关UI页面布局的大量信息。我创建了嵌入哪些组件的列表，其中我使用XSLT写入我们的模式定义。

此外，来自C ++背景，它是一种非常有趣和有趣的语言。

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

具体到您的示例，我认为最好的想法是创建您自己的遵循业务逻辑的XML-＆gt; XML转换。接下来，编写一个XSLT转换器，它只知道格式化并且没有任何巧妙之处。这可能是一个很好的中间地带，但这完全取决于你在做什么。在输出上安装XSLT转换器可以更轻松地创建替代输出格式 - 可打印，适用于移动设备等。

Answer 10

是的，我经常使用它。通过使用不同的xslt文件，我可以使用相同的XML源创建多个多语言（X）HTML文件（以不同方式呈现相同的数据），RSS提要，Atom提要，RDF描述符文件和站点地图的片段

这不是灵丹妙药。有些事情做得很好，事情做得不好，就像编程的所有其他方面一样，所有关于使用正确的工具来做正确的工作。这是一个非常值得在您的工具箱中使用的工具，但只有在适合的情况下才能使用它。

Answer 11

我肯定会建议坚持下去。特别是如果您使用的是Visual Studio，它内置了XSLT的编辑，查看和调试工具。

是的，在你学习的过程中，这是一种痛苦，但大部分的痛苦都与熟悉有关。当你学习语言时，痛苦会减少。

W3schools有两篇特别值得的文章： http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Answer 12

我在2004年的某个时候在非常不相似的数据库系统之间的集成项目中使用了XML，XSD和XSLT。我不得不从头开始学习XSD和XSLT，但这并不难。这些工具的优点在于它使我能够编写独立于数据的C ++代码，依靠XSD和XSLT来验证/验证然后转换XML文档。更改数据格式，更改XSD和XSLT文档，而不是使用Xerces库的C ++代码。

感兴趣：主XSD为150KB，XSLT的平均大小<150。 5KB IIRC。

另一个很大的好处是XSD是XSLT所基于的规范文档。两者和谐共处。如今，软件开发中的规格很少见。

虽然我在学习声明性XSD和XSLT方面没有太多麻烦，但我确实发现其他C / C ++程序员在调整声明方式方面遇到了很大麻烦。当他们看到那是它的时候，他们嘀咕着程序，现在我明白了！他们继续（双关语）编写程序XSLT！问题是你必须学习XPath并理解XML的轴。让我想起过时的C程序员在编写C ++时适应OO。

我使用这些工具，因为它们使我能够编写一个与最基本的数据结构修改隔离的小C ++代码库，后者是DB结构更改。尽管我更喜欢C ++和其他任何语言，但我会使用我认为对软件项目的长期可行性有用的东西。

Answer 13

我发现XSLT很难使用。

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

选择结果是灾难性的。事实证明，XSLT写起来很痛苦。所以我们所有的页面都难以编写和维护。我们会更好地使用JSP（这是用Java）或类似的方法，使用一种标记（尖括号）作为输出格式（HTML）和另一种标记（如＆lt;％.. 。％＆gt;）用于元数据。关于XSLT最令人困惑的事情是它是用XML编写的，它从XML转换为XML ......很难将所有3种不同的XML文档直接放在一个人的脑海中。

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

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

- Michael Chermside

Answer 14

我曾经认为XSLT是个好主意。我的意思是是一个好主意。

失败的地方是执行。

我随着时间的推移发现的问题是XML中的编程语言只是一个坏主意。它使整个事物难以穿透。具体来说，我认为XSLT非常难学，代码和理解。功能方面的XML只会让整个事情变得混乱。在我的职业生涯中，我曾尝试过5次学习它，但它并没有坚持下去。

好的，你可以'工具'它 - 我认为这部分是它的设计点 - 但这是第二次失败：市场上的所有XSLT工具都非常简单......废话！

Answer 15

XSLT很难使用，但是一旦你征服它，你就会对DOM和架构有一个非常透彻的了解。如果你也是XPath，那么你正在学习函数式编程，这将揭示解决问题的新技术和方法。在某些情况下，连续转换比程序解决方案更强大。

Answer 16

我广泛使用XSLT，用于自定义MVC风格的前端。该模型被“序列化”为xml（不是通过xml serializaiton），然后通过xslt转换为html。与ASP.NET相比，优势在于与XPath的自然集成，以及更严格的格式要求（在xslt中推理文档结构比在大多数其他语言中更容易）。

不幸的是，该语言包含一些限制（例如，转换另一个转换的输出的能力），这意味着它偶尔会令人沮丧。

然而，它给予的容易实现的，强烈强制的关注点分离并不是我现在看到的另一种技术 - 所以对于文档转换它仍然是我推荐的。

Answer 17

XSLT specification将XSLT定义为“将XML文档转换为其他XML文档的语言”。如果您尝试做任何事情，除了XSLT中最基本的数据处理，可能有更好的解决方案。

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

Answer 18

归结为你需要它。它的主要优点是转换的易维护性，编写自己的解析器通常会消除它。话虽如此，有时系统很小而且简单，实际上并不需要“花哨”的解决方案。只要基于代码的构建器可以替换而不必更改其他代码，就没什么大不了的。

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

Answer 19

如果你能以声明的方式使用XSLT（虽然我不完全同意它是声明性语言），那么我认为它是有用的和富有表现力的。

我编写的Web应用程序使用OO语言（在我的情况下为C＃）来处理数据/处理层，但是输出XML而不是HTML。然后，客户端可以将其直接作为数据API使用，或者通过XSLT呈现为HTML。因为C＃输出的XML在结构上与这种用法兼容，所以它非常流畅，并且表示逻辑保持声明性。比从C＃发送标签更容易理解和更改。

但是，由于在XSLT级别需要更多处理逻辑，因此即使您“获得”功能样式，它也会变得复杂和冗长。

当然，这些天我可能已经使用RESTful接口编写了这些Web应用程序 - 我认为像JSON这样的数据“语言”在传统上由XSLT转换的XML领域正在获得关注。但是现在XSLT仍然是一项重要且有用的技术。

Answer 20

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

这使我们可以轻松更改文档布局而无需进行任何编码。它只是改变XSLT的问题。

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

此外，通过使用XSLT，您正在更接近问题域（HTML）。我一直认为这是个好主意。

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

Answer 21

我仍然认为XSLT可能很有用，但它是一种丑陋的语言，可能导致一个难以理解的，难以维护的混乱。部分原因是因为XML不足以构成一种“语言”，部分原因是因为XSLT被置于声明性和程序性之间。话虽如此，我认为可以用正则表达式进行比较，但是当涉及到简单明确的问题时，它就有了它的用途。

使用替代方法并在代码中解析XML可能同样令人讨厌，并且您确实希望使用某种XML编组/绑定技术（例如Java中的JiBX）将XML直接转换为对象。

Answer 22

xslt真正闪耀的一个地方是生成报告。我发现了一个两步过程，第一步是将报告数据导出为xml文件，第二步是使用xslt从xml生成可视化报告。这样可以提供漂亮的可视化报告，同时在需要时仍然保留原始数据作为验证机制。

Answer 23

我之前使用过XSLT。在我用C＃重写之前，6个.xslt文件组（由一个大文件重构）大约是2750行。 C＃代码目前有4000行包含大量逻辑;我甚至不想考虑在XSLT中编写的内容。

我放弃的地方是当我意识到XPATH 2.0没有显着损害我的进步时。

Answer 24

在之前的公司，我们使用XML和XSLT做了很多工作。 XML和XSLT都很重要。

是的，有一个学习曲线，但是你有一个强大的工具来处理XML。你甚至可以在XSLT上使用XSLT（有时候它很有用）。

性能也是一个问题（使用非常大的XML）但您可以通过使用智能XSLT解决这个问题，并使用（生成的）XML进行一些预处理。

任何了解XSLT的人都可以改变成品的外观，因为它没有编译。

Answer 25

我个人喜欢XSLT，你可能想要simplified syntax看一下（没有明确的模板，只是一个带有一些XSLT标签的常规旧HTML文件，可以将值吐入其中），但它只是'适合所有人。

也许您只想为作者提供简单的Wiki或Markdown界面。也有这样的库，如果XSLT不适合你，也许XML也不适用于它们。

Answer 26

回答你的三个问题：

几年前我曾使用过XSLT。
我相信在某些情况下XSLT可能是正确的解决方案。（永远不要说永远不会）
我倾向于同意你的评价，即它对“简单”转换最有用。但我认为只要你很好地理解XSLT，就可以将其用于更大的任务，例如将XML作为XML转换为HTML来发布。

我相信许多开发人员不喜欢XSLT的原因是因为他们不了解它所基于的根本不同的范例。但随着最近对函数式编程的兴趣，我们可能会看到XSLT卷土重来......

Answer 27

我目前的任务是从公共站点抓取数据（是的，我知道）。值得庆幸的是它符合xhtml所以我能够使用xslt来收集我需要的数据。如果需要，最终的解决方案是可读的，清洁的并且易于更改。完美！

Answer 28

我花了很多时间在XSLT中发现虽然它在某些情况下是一个有用的工具，但绝对不是一个全部修复。当它用于机器可读XML输入/输出的数据转换时，它非常适用于B2B目的。我不认为你在其限制声明中走错了路。让我感到沮丧的一件事是XSLT实现中的细微差别。

也许您应该查看一些其他可用的标记语言。我相信Jeff做了一篇关于Stack Overflow这个话题的文章。

Is HTML a Humane Markup Language?

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

Answer 29

我认为这个概念是合理的，也许执行不像它那样“干净”。

但是我认为它应该被视为一种工具，在每个实例中使用它可能都不明智，但是在解决方案时不应忽视工具。

我已经看到非常好的XSLT，也非常糟糕地使用XSLT，我得出结论，其中一些可能取决于开发人员的技能。我认为它需要开发人员同时在多个域中进行思考。

是未来吗？也许不是，也许有更好的解决方案......

我不知道会有什么新技术出现，但至少最好学习它，增加自己的工具集肯定不是坏事吗？

Answer 30

我确实广泛使用了XSLT ......几个小时。对于诸如更改元素名称或过滤输入文档（剥离你不需要的东西）这样的东西来说很酷。

其他任何事情都很快变得复杂。这继承了复杂性以及你从任何其他编程语言（如变量）中使用的大多数东西的缺乏以及使XPath表达式不可读的简单方法，真的很痛苦。

最后，XSLT患有schisma：程序员不喜欢它，因为有限制，其他人根本不能使用它（比如网页设计师或任何其他非程序员类型）。

如果XSLT被提升为XML的某种SQL，那么事情会有所不同。首先，人们甚至不愿意去看它。那些做过的人不会对这种痛苦感到惊讶。

Answer 31

我使用XSLT来纠正非常复杂的xml文件中的错误。因此，不使用xslt处理xml中的错误，而是使用xslt来纠正错误。

这很棒。因为语言是如此强大，它适合xml用例。要在一个因果编程语言中做同样的事情，每次出现新的风格时，我需要花费很长的时间来调整我的代码。

它还可以用于迁移visual studio解决方案，而不会让microsoft决定改变哪些事情。转换一个解决方案。检查改变了什么。恢复您不想更改的内容并运行xslt脚本在所有文件上执行作业。

所以我从来没有用它来做网络演示或类似的东西，但它帮助我解决基于xml的问题。要解决这些问题，它真的非常强大，值得一看。

Answer 32

在我看来是的。

有关使用XSLT的一个很好的例子，请查看暴雪的魔兽世界军械库。

http://www.wowarmory.com

Answer 33

谈到互操作性，XML是信息存储的标准。大量工具以XML格式生成输出，以及比在应用程序中嵌入浏览器并将XML格式化并将其放入浏览器更好（或更简单）的方式。

Answer 34

我需要在这里使用XSLT，因为有些人认为解决给定问题是个好主意：我们需要从多个XML文件中提取一些数据并将它们连接到不同的输出格式，以便进一步完成处理

Fisrt我认为XSLT是一个非常好的主意，因为它是您可以信赖的标准。对于简单的格式化任务，您的代码中不需要太多的编程逻辑或算法就是如此。

但是：这是一个相当一步的学习曲线，因为它不是程序性的。如果您已经习惯了程序编程（C，Java，Perl，PHP等），那么您将会错过很多常见的结构，或者您会想到那些只是运气的东西，有时候不会被未经训练的眼睛读取。例如，编写“可重复使用”代码：如果需要在不同的地方反复执行某些操作，在过程编程中，您将定义一个函数来执行此操作。你也可以在XSLT中实现这样的东西，但它需要更多的代码来编写，并且不像普通函数那样可读/可理解。

我遇到的主要问题是，许多从程序背景出发的人现在都在使用XSLT-Files，而且几乎每个人都“模仿”了他需要的东西。

结论是：我不认为XSLT是“终极”解决方案了。事实上，在XSLT中读取或编写一些构造是很痛苦的。对于大多数情况，您将不得不考虑应用程序：对于简单的转换，我可能会再次使用XSLT。但对于更复杂的软件，我不会再使用它了。

Answer 35

我认为你做对了。根据我的经验，XSLT开发人员是最难雇用的人之一，因为它是一种从未与Web开发人员或临时程序员相关的语言。

所以你最终不得不支付“知道主流以外语言的高级程序员”的费用，但对于一种可能不是程序员最喜欢的语言。

Answer 36

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

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

Answer 37

就纯粹的生产力而言，最好使用其中一个jQuery样式的库 - pyQuery，phpQuery等。大多数XML库很糟糕，而XSLT本质上只是另一个XML库，打包成一个完整的语言，但没有一个像样的一套工具。 jQuery使用您选择的语言遍历和操作XML样式数据变得非常容易。

Answer 38

我也进入了XSLT的世界，我发现它在某些地方有点尴尬。我认为我的主要问题是难以将“纯数据”XML转换为完整的HTML页面。事后看来，使用XSLT生成可以使用服务器端脚本（例如SSI）与其他片段一起组成的页面片段可能会解决我的许多问题。

可能的错误之一是尝试通过使用document（）函数导入XHTML或其他XML数据来构建公共页面布局以包围我的数据。

另一个错误是尝试编写一些程序化的东西，例如创建一个通用模板来生成XML数据上的表格，这些逻辑可以为具有特定值的行使用不同的背景行颜色，并允许您指定要过滤掉的某些列。

更不用说尝试从XML数据构造一个字符串列表，这些值似乎只能使用递归模板调用来解决。

我获得了什么？好吧，页面源是XML数据，可供查看者使用。数据和演示文稿完全分开。

我会再做一次吗？可能不是，除非我真的想在静态页面上分享数据/表示。否则，我可能会编写一个Rails或Java EE应用程序，它可以使用模板生成XML视图或HTML视图 - 所有的好处，但在我的指尖使用更自然的（对我来说）编程语言。

Answer 39

XSLT并不是xml转换的最终结果。但是，根据所提供的信息判断它是否是您问题的最佳解决方案，或者是否存在其他更有效和可维护的方法是非常困难的。你说作者可以用简化的格式输入他们的内容 - 什么格式？文字框？你把它转换成什么样的HTML？要判断XSLT是否适合这项工作，将有助于更详细地了解此转换的功能。

Answer 40

我在XSLT方面有过相当不错的经验，但我没有转化为HTML。可能是XSLT-HTML组合对于完成任务非常困难。

Answer 41

XSLT 1.0是最便携的代码之一，至少在台式机和服务器计算机上是如此。因为它在大多数系统上有一个（通常很多）运行时：

Microsoft Windows至少有Windows 2000安装在基本系统中的MSXML。它可以在MSIE，from the command line（使用WSH）或Office应用程序中使用
Java运行时环境（JRE）具有XSLT运行时，并且大多数桌面上都安装了JRE
几乎所有主流网页浏览器都有一个。 Opera是个例外。
默认情况下，在基于GNU的主要操作系统上安装了免费实现（libxslt，xsltproc）
我没有检查过MacOS X，但它至少在Safari中实现了

这使得它非常适合构建一些既需要可移植性又需要轻量级/无需安装的应用程序。

此外，XSLT只需要运行时（无需编译器），您只需使用任何文本编辑器即可创建代码。因此，您可以从任何桌面轻松创建程序（一旦掌握了语言）。

XSLT值得吗？

41 个答案: