it-swarm.cn

XSLT值得吗?

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

我至今仍在努力(我实际上应该正在努力,而不是在SO),我看到越来越多让我觉得放弃XSLT的决定很好的事情。

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

110
nickf

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更简单的输入格式。

63
Steve Jessop

这么多的消极性!

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

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

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

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

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

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

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

88
annakata

我不得不承认这里存在偏见,因为我教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的实现。但它仍然存在,并且从我的观点来看似乎变得强大。

27
Nic Gibson

我们广泛使用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),我们最终得到Nice发行说明(通常是PDF或HTML),其中错误ID自动链接到我们的错误跟踪器,错误按组件分组,并且所有内容的格式完全一致。并且可以通过查询我们的错误跟踪器来自动生成上述XML,以了解版本之间的变化。

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

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

24
Adam Batkin

XSLT是 声明性编程 语言的一个例子。

声明性编程语言的其他示例包括正则表达式,Prolog和SQL。所有这些都具有高度的表现力和紧凑性,并且通常设计得非常好,并且对于它们的设计任务非常有用。

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

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

19
Bill Karwin

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

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

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

12
Crusty

我已经广泛地使用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实现。

10
Pavel Minaev

我使用XSLT(缺少更好的替代方案),但不用于演示,仅用于转换:

  1. 我编写了简短的XSLT转换来对我们的maven pom.xml文件进行批量编辑。

  2. 我编写了一个转换管道,用于从XMI(UML Diagram)生成XML Schema。它工作了一段时间,但它最终变得太复杂了,我们不得不把它带到谷仓后面。

  3. 我使用转换来重构XML Schema。

  4. 我已经解决了XSLT中的一些限制,通过使用它来生成XSLT来完成实际工作。 (曾经尝试编写一个使用命名空间生成输出的XSLT,这些命名空间直到运行时才知道吗?)

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

也就是说,我正在调查使用 Clojure (一个LISP)来执行XML的转换,但我还没有充分了解这种方法是否会给我带来好处。

9
bendin

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

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

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

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

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

7
Tom Leys

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

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

6
Alohci

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

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

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

4
Nat

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

3
David Robbins

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

失败的地方是执行。

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

好吧,你可以“工具”它 - 我认为这部分是它的设计点 - 但这是第二次失败:市场上的所有XSLT工具都非常简单......废话!

3
Schneider

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

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

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

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

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

3
Sam

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

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

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

3
Eamon Nerbonne

我发现XSLT很难处理。

我有一个与你描述的系统有点类似的系统工作经验。我的公司注意到我们从“中间层”返回的数据是XML格式,并且页面将以HTML格式呈现,也可能是XHTML,而且他们听说XSL是XML之间转换的标准。格式。因此,“架构师”(我指的是那些认为深刻的设计思想但显然从不编码的人)决定通过编写将数据转换为XHTML进行显示的XSLT脚本来实现我们的前端层。

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

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

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

- Michael Chermside

3
mcherm

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

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

2
SpongeJim

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

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

2
Eric Schoonover

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

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

2
Tom Martin

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

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

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

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

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

2
Mashed Potato

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

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

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

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

2
philsquared

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

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

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

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

1
Toon Krijthe

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

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

1
Sam Harwell

回答你的三个问题:

  1. 几年前我曾经使用过XSLT。
  2. 我相信XSLT在某些情况下可能是正确的解决方案。 (永远不要把话说绝了)
  3. 我倾向于同意你的评价,它对“简单”转换最有用。但我认为只要你很好地理解XSLT,就可以将其用于更大的任务,例如将XML作为XML转换为HTML。

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

1
Dawie Strauss

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

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

HTML是一种人道标记语言吗?

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

1
Jason Jackson

Xslt真正闪耀的一个地方是生成报告。我发现了一个两步过程,第一步是将报告数据导出为xml文件,第二步是使用xslt从xml生成可视化报告。这允许Nice视觉报告,同时仍然保留原始数据作为验证机制,如果需要的话。

1
Jack Ryan

我个人喜欢XSLT,你可能想要 简化语法 一看(没有显式模板,只是一个带有一些XSLT标签的常规旧HTML文件,可以将值吐入其中),但它不适用于大家。

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

1
brianary

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

1
Goran

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

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

0
Larry OBrien

我对XSLT有相当不错的经验,但我没有转换成HTML。可能是XSLT-HTML组合对于完成任务非常困难。

0
Rolf

在我看来是的。

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

http://www.wowarmory.com

0
Vinh

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

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

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

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

0
dolmen

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

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

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

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

0
Aaron Digulla

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

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

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

这是未来吗?也许不是,也许有更好的解决方案..

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

0
Darknight

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

这很棒。因为语言是如此强大,它适合xml用例。要用ususal编程语言做同样的事情,每次出现新的味道时,我都需要花很长时间来调整我的代码。

它还可用于迁移Visual Studio解决方案,而无需微软决定改变哪些内容。转换一个解决方案。检查改变了什么。恢复您不想更改的内容并运行xslt脚本在所有文件上执行作业。

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

0
Totonga

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

0
Shmoggle

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

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

另一个错误是尝试编写一些程序化的东西,例如创建一个通用模板来生成XML数据表,逻辑执行的操作就像对具有特定值的行使用不同的背景行颜色,并允许您指定一些要过滤的列。

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

我获得了什么?好吧,页面源是XML数据,可供查看者使用。数据和演示文稿整齐地分开。

我会再做一次吗?可能不是,除非我真的想在 static page上分享数据/表示。否则,我可能会编写一个Rails或Java EE应用程序,它可以使用模板生成XML视图或HTML视图 - 所有的好处,但在我的指尖使用更自然(对我而言)的编程语言。

0
Mike Tunnicliffe

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

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

0
Ben

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

0
Jimmy

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

0
Midhat

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

Fisrt我认为XSLT是一个非常好的主意,因为它是你可以信赖的标准。这对于简单的格式化任务来说是正确的,在这些任务中,您不需要在代码中使用太多的编程逻辑或算法。

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

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

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

0
Murphy