XSLT值得吗?

前一段时间,我开始了一个项目,在那里我devise了一个html-esque的XML模式,以便作者能够以简化的格式编写他们的内容(教育课程材料),然后通过XSLT将其转换为HTML。 我玩了一段时间,并把它弄到一个非常基本的水平,但后来因为我遇到的限制而感到非常恼火(这可能是我的知识的限制),而且当我读博客时build议去沟XSLT,只要用你自己select的语言编写你自己的XML到任何parsing器,我就急于跳到这个语言上,并且出色地完成了。

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

我知道XSLT有其自身的地位,因为它是一个公认的标准,如果每个人都在写自己的口译人员,他们中的90%最终会在TheDailyWTF上出现 。 但是鉴于这是一种function性风格的语言,而不是大多数程序员熟悉的程序风格,对于像我自己这样开始项目的人, 你会推荐他们走下我所做的道路,还是用XSLT

XSLT的优点:

  • 特定于域的XML,例如,不需要在输出中引用文字XML。
  • 支持XPath / XQuery,这是一种查询DOM的好方法,正则expression式可以成为查询string的好方法。
  • function语言。

XSLT的缺点:

  • 可以是淫秽的冗长 – 你不必引用文字XML,这实际上意味着你必须引用代码。 而不是一个漂亮的方式。 但是再一次,它不比你的典型SSI差太多。
  • 不要做大多数程序员认为理所当然的事情。 例如string操作可能是一件杂事。 当新手devise代码时,这可能会导致“不幸的时刻”,然后疯狂地searchnetworking提示如何实现他们认为只是在那里的function,没有时间写。
  • function语言。

顺便获得程序行为的一种方式是将多个变换链接在一起。 在每一步之后,你都有一个全新的DOM来工作,这反映了这一步的变化。 一些XSL处理器有扩展,可以在一次转换中有效地做到这一点,但我忘记了细节。

所以,如果你的代码大部分是输出而不是很多的逻辑,那么XSLT可以是一个很好的expression方式。 如果有很多的逻辑,但主要是内置到XSLT的forms(select所有元素看起来像是等等,每个输出等等),它可能是一个相当友好的环境。 如果你喜欢随时想XML,那么就给XSLT 2一下。

否则,我会说,如果你最喜欢的编程语言有一个很好的支持XPath的DOM实现,并允许你以一种有用的方式构build文档,那么使用XSLT就没有什么好处了。 绑定到libxml2和gdome2应该很好,并且坚持使用你熟悉的通用语言并不是件难事。

本土化的XMLparsing器通常不完整(在这种情况下,你将会在某一天失去存储空间),否则就不会比你能够下架的东西(在这种情况下你可能正在浪费你的时间)小得多,你有任何机会围绕恶意input引入严重的安全问题。 不要写一个,除非你确切地知道你从中得到了什么。 如果你不需要XML提供的所有东西,那么就不能说你不能为比XML更简单的语法编写parsing器。

非常消极!

我已经使用XSLT好几年了,真的很喜欢它。 你必须意识到的关键是, 它不是一种编程语言,它是一种模板语言 (在这方面,我觉得它不可思议地优于asp.net / spit)。

XML是当今Web开发事实上的数据格式,无论是configuration文件,原始数据还是内存再分析。 XSLT和XPath为您提供了一种非常强大且非常高效的方法,可以将数据转换为您可能喜欢的任何输出格式,并即时为您提供从数据中分离演示的MVC方面。

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

处理XSLT比开发自己的内部方法要好一些。 至lessXSLT是一个标准,你可以聘请一些东西,如果这对你的团队来说真的是一个问题,那么很自然就会让你的大部分团队只用XML。

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

就我个人而言,我认为这是我在职业生涯中遇到的最干净的事情之一,我相信所有显而易见的问题(debugging,string处理,编程结构)都是对这个工具有缺陷的理解。

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

我不得不在这里承认一个偏见,因为我教XSLT谋生。 但是,这可能是值得我看到我的学生工作的地区。他们一般分为三类:出版,银行和networking。

到目前为止,许多答案可以概括为“创build网站没有好处”或“与X语言无关”。 许多技术人员在职业生涯中没有接触到function/陈述语言。 当我在教学时,经验丰富的Java / VB / C /等人就是那些对语言有问题的人(variables是代数意义上的variables而不是程序编程)。 这是很多人在这里回答 – 我从来没有使用Java,但我不打算因此而批评语言。

在许多情况下,它是创build网站的不恰当工具 – 通用编程语言可能会更好。 我经常需要将非常大的XML文档呈现在网页上; XSLT使这个微不足道。 我在这个领域看到的学生倾向于处理数据集并在networking上呈现。 XSLT当然不是这个领域唯一适用的工具。 然而,他们中的许多人正在使用DOM来做到这一点,XSLT肯定不那么痛苦。

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

我看到的最后一批学生来自出版背景(像我一样)。 这些人倾向于在XML中拥有巨大的文档(相信我,出版业作为一个行业正在进入XML – 技术出版已经存在多年,贸易出版现在已经到了那里)。 这些文件需要进行处理(DocBook到ePub这里才浮现)。

上面有人评论说,脚本往往低于60行,或变得笨重。 如果它变得笨拙的话,编码人员的可能性并不是真的有这样的想法 – XSLT与其他许多语言的思维模式是截然不同的。 如果你没有得到的心态,它将无法正常工作。

这当然不是一个垂死的语言(我得到的工作量告诉我)。 现在,在微软完成XSLT 2的(非常晚的)实现之前,它有点“卡住”了。但是它仍然存在,从我的angular度来看似乎很强劲。

我们广泛地使用XSLT来处理文档等事情,并使一些复杂的configuration设置成为用户可用的。

对于文档,我们使用了很多DocBook,这是一种基于XML的格式。 这使我们可以存储和pipe理我们的所有源代码文档,因为这些文件是纯文本的。 借助XSLT,我们可以轻松构build自己的文档格式,从而使我们能够以通用方式自动生成内容,并使内容更具可读性。 例如,当我们发布发行说明时,我们可以创build如下所示的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),其中bug ID自动链接到我们的bug跟踪器,bug按组件分组,并且所有事情的格式完全一致。 上面的XML可以通过查询我们的bug跟踪器来自动生成版本之间的变化。

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

我想说,对于Web项目来说,现在有比XSLT更好的方式来处理视图方面,但作为一种技术,XSLT肯定是有用的。 这不是世界上最容易使用的语言,但绝对不是死的,从我的angular度来看还是有很多好用的。

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

声明性编程语言的其他例子包括正则expression式,Prolog和SQL。 所有这些都具有很强的performance力和紧凑性,而且通常devise得非常好,而且function强大。

然而,软件开发人员通常讨厌这样的语言,因为它们与更主stream的面向对象程序或程序语言是截然不同的,他们很难学习和debugging。 它们紧凑的性质一般很容易在不经意间造成很大的伤害。

所以尽pipeXSLT是将数据合并到表示中的有效机制,但它在易用性部门中失败了。 我相信这就是为什么它没有真正的抓住。

当标准刚刚发布的时候,我记得所有关于XSLT的宣传。 所有的兴奋都可以通过一个简单的转换来构build一个完整的HTML UI。

让我们面对它,这是很难使用,几乎不可能debugging,往往难以忍受的慢。 最终的结果几乎总是古怪而不甚理想。

我会更快地啃掉自己的腿,而不是使用XSLT,而有更好的方法来做事。 它仍然有它的地方,它对于简单的变换任务是有好处的。

我已经广泛地使用XSLT(也包括XQuery)来生成各种各样的东西 – 生成C ++代码作为构build过程的一部分,从doc注释生成文档,以及在一般的应用程序中使用XML,尤其是XHTML 。 特别是代码生成器超过了10,000行的XSLT 2.0代码,散布在大约十几个单独的文件中(它为客户端,远程代理/存根,COM封装器,.NET封装器,ORM做了许多事情)一些)。 我inheritance了另外一个不太了解语言的人,因此老一点的东西相当混乱。 我们写的新东西大多保持清晰可读,但是我不记得有什么特别的问题可以实现。 这当然不比C ++更难。

说到版本,处理XSLT 2.0肯定有助于保持理智,但对于简单的转换,1.0仍然可以。 在它的利基,它是一个非常方便的工具,并从特定的领域特定的function(最重要的是,通过模板匹配的dynamic调度),你的生产力很难匹配。 尽pipeXSLT的基于XML的语法有一定的歧义性,但是在LINQ to XML(甚至在VB中使用XML文字)中的相同事情通常要长数倍。 然而,经常在某些情况下,由于不必要地使用XML而导致错误的结果。

总而言之,这是一个非常有用的工具,但它是一个非常专业化的工具,所以只要你正确地使用它并达到它的目的,它就是好的。 我真的希望有一个适当的本地.NET实现的XSLT 2.0。

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

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

  2. 我已经编写了一个转换stream水线来从XMI(UML Diagram)生成XML Schema。 它工作了一段时间,但它终于太复杂了,我们不得不把它在谷仓后面。

  3. 我已经使用转换来重构XML模式。

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

我不断回来,因为它比我尝试过的其他方法更好地处理它正在处理的XML,这些方法似乎是不必要的损失或者只是误解了XML。 XSLT是不愉快的,但我发现使用氧气使它可以忍受。

也就是说,我正在调查使用Clojure (一个lisp)来执行XML的转换,但是我还没有得到足够的信息来知道这种方法是否会给我带来好处。

就我个人而言,我在完全不同的上下文中使用了XSLT。 我当时正在使用的计算机游戏使用了大量使用XML定义的UI页面。 在发布不久之后的一个主要的重构过程中,我们想要改变这些XML文档的结构。 我们使游戏的input格式遵循更好的和模式感知的结构。

XSLT似乎是旧格式翻译的最佳select – >新格式。 在两周之内,我们有数百页的从旧到新的转换。 我也能够使用它来提取我们的UI页面布局的大量信息。 我创build了哪些组件被embedded的列表,这些列表相对容易,然后使用XSLT写入我们的模式定义。

另外,来自C ++的背景,这是一个非常有趣和有趣的语言掌握。

我认为,作为将XML从一种格式转换为另一种格式的工具,这是太棒了。 但是,定义一个将XML作为input并输出Something的algorithm并不是唯一的方法。 如果你的algorithm足够复杂,那么input是XML的事实与你select的工具无关 – 也就是在C ++ / Python /里面自己编译。

具体到你的例子,我想最好的想法是创build你自己的XML-> XML转换,遵循你的业务逻辑。 接下来,写一个XSLT翻译器,它只是知道格式,并没有什么聪明的。 这可能是一个很好的中间地带,但完全取决于你在做什么。 在输出上使用XSLT转换器可以更容易地创build替代输出格式 – 可打印的,用于移动设备等。

是的,我用了很多。 通过使用不同的xslt文件,我可以使用相同的XML源创build多个polyglot(X)HTML文件(以不同的方式显示相同的数据),RSS提要,Atom提要,RDF描述符文件和站点地图片段。

这不是万能的。 有些事情做得很好,事情做得不好,像编程的所有其他方面一样,都是使用正确的工具来做正确的工作。 这是一个非常值得在工具箱中使用的工具,但只有在适当的情况下才能使用。

我肯定会build议坚持下去。 特别是如果您正在使用内置了用于XSLT的编辑,查看和debugging工具的Visual Studio。

是的,在你学习的时候,这是一种痛苦,但是大部分的痛苦是与熟悉有关。 当你学习这门语言时,疼痛会消失。

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

我发现XSLT相当困难。

我曾经有过一个与你描述的系统有点类似的系统。 我的公司指出,我们从“中间层”返回的数据是用XML表示的,页面是用HTML来表示的,这也可能是XHTML,再加上他们听说XSL是在XML之间转换的标准格式。 所以“架构师”(我指的是那些认为深度devise思想但明显从不代码的人)决定通过编写将数据转换成XHTML来显示的XSLT脚本来实现我们的前端层。

select结果是灾难性的。 事实certificate,XSLT是一个很难写的东西。 所以我们所有的页面都很难写和维护。 使用JSP(这是用Java语言编写的)或者一些类似的方法,使用输出格式(HTML)的一种标记(尖括号)和另一种标记(比如<%…) %>)的元数据。 关于XSLT最令人困惑的是,它是用XML编写的,它从XML转换成XML ……想要把所有3种不同的XML文档保持一致是非常困难的。

您的情况稍有不同:不像我这样在XSLT中创build每个页面,只需要在XSLT中编写一个代码(从模板转换为显示的代码)。 但是,听起来你可能碰到了和我一样的困难。 我想说的是,试图解释一个简单的基于XML的DSL(域特定语言)就像你正在做的不是XSLT的强项之一。 (尽pipe它可以完成这项工作…毕竟,它是图灵完成!)

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

Michael Chermside

XSLT很难处理,但是一旦你征服了它,你将对DOM和模式有一个非常透彻的理解。 如果你也是XPath的话,那么你在学习函数式编程的道路上,这将暴露出新的技术和解决问题的方法。 在某些情况下,连续转换比程序化解决scheme更为强大。

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

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

尽pipe如此,我们所看到的另一项技术并不是我现在所能提供的另一种技术,因此对于文档转换,我仍然会推荐它。

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

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

另一个很大的好处是XSD是XSLT所基于的规范文档。 两人和睦相处。 目前规范在软件开发中很less见。

虽然我没有太多的麻烦学习声明性的XSD和XSLT,但是我发现其他C / C ++程序员在调整声明方式方面遇到了很大的麻烦。 当他们看到这个时候,他们喃喃自语的程序,现在我明白了! 他们继续(双关语)编写程序化的XSLT! 问题是你必须学习XPath并理解XML的轴。 提醒我在编写C ++时习惯使用OO的C程序员。

我使用了这些工具,因为它们使我能够编写一个小型的C ++代码库,这个C ++代码库除了最基本的数据结构修改之外都是隔离的,而后者是DB结构的变化。 尽pipe我更喜欢C ++到任何其他语言,但我会使用我认为有益于软件项目的长期可行性。

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

执行失败的地方。

随着时间的推移,我发现的问题是XML中的编程语言只是一个坏主意。 它使整个事情变得难以逾越。 具体而言,我认为XSLT是非常艰苦的学习,代码和理解。 function方面的XML只是让整个事情变得混乱。 在我的职业生涯中,我尝试了5次左右的学习,但并不坚持。

好吧,你可以'工具' – 我认为这是它的devise的一部分 – 但这是第二次失败:市场上所有的XSLT工具,很简单…废话!

XSLT规范将XSLT定义为“将XML文档转换为其他XML文档的语言”。 如果您正在尝试除XSLT中最基本的数据处理之外的任何事情,那么可能会有更好的解决scheme。

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

  • MSDN文档
  • CSharpFriends:教程

我为我的公司维护一个在线文档系统。 编写者在SGML中创build文档(类似于xml的语言)。 然后将SGML与XSLT结合并转换成HTML。

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

这对我们很好。 在我们的例子中,它是一个只读文件。 用户不与文档进行交互。

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

最后,如果您目前的系统正常工作,请保持独立。 我永远不会build议摧毁你现有的代码。 如果我从头开始,我会使用XSLT,但在你的情况下,我会使用你的。

这归结于你所需要的。 它的主要优点是转换的易维护性,编写自己的parsing器通常会消除这种情况。 有了这个说法,有时一个系统是小而简单的,真的不需要一个“奇特”的解决scheme。 只要你的代码生成器是可replace的,而不必更改其他代码,没有什么大不了的。

至于XSL的丑陋,是的,这是丑陋的。 是的,这需要一些习惯。 但一旦你掌握了它(不应该需要很长时间的海事组织),它实际上是一帆风顺的。 根据我的经验,编译转换的速度相当快,您当然可以debugging它们。

我仍然相信XSLT是有用的,但它是一个丑陋的语言,可能会导致一个可怕的,难以理解的,难以维护的混乱。 部分原因是由于XML不足以构成“语言”,部分原因是XSLT处于声明式和程序式之间。 话虽如此,我认为可以用正则expression式来进行比较,但对于简单的定义明确的问题来说却是有用的。

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

如果你可以在声明式风格中使用XSLT(尽pipe我不完全同意它是声明式语言),那么我认为这是有用的和expression性的。

我已经编写了使用OO语言的Web应用程序(在我的情况下是C#)来处理数据/处理层,但输出XML而不是HTML。 然后这可以由客户端直接作为数据API使用,或者由XSLT呈现为HTML。 因为C#输出的XML在结构上与这个用法相兼容,所以非常stream畅,expression逻辑保持声明。 比从C#发送标签更容易跟踪和更改。

但是,由于您在XSLT级别需要更多的处理逻辑,所以它会变得复杂而冗长 – 即使您“获得”了function样式。

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

我在XSLT上花了很多时间,发现它在某些情况下是一个有用的工具,但它绝对不是一个解决scheme。 当用于机器可读的XMLinput/输出的数据转换时,它可以很好地用于B2B目的。 我不认为你在陈述其局限性方面是错误的。 最令我沮丧的事情之一是XSLT实现中的细微差别。

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

HTML是一种人性化的标记语言吗?

我会看看他写的东西。 你也许可以find一个软件包,它可以“开箱即用”的方式做你想做的事情,或者至less非常接近,而不是从头开始编写自己的东西。

我目前的任务是从公共网站上抓取数据(是的,我知道)。 谢天谢地,它符合xhtml,所以我可以使用xslt来收集我需要的数据。 由此产生的解决scheme是可读的,干净,容易改变,如果需要的话。 完善!

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

我放弃的一点是,当我意识到没有XPATH 2.0显着地伤害了我的进步。

回答你的三个问题:

  1. 我几年前曾经使用过XSLT。
  2. 我相信XSLT在某些情况下可能是正确的解决scheme。 (永不说永不)
  3. 我倾向于同意你的评价,认为这对“简单”的转变是最有用的。 但是我认为,只要你理解了XSLT,就可以将它用于更大的任务,比如将XML转换成HTML的网站。

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

xslt真正闪耀的一个地方就是生成报告。 我发现这是一个2步骤的过程,第一步将报告数据导出为xml文件,第二步使用xslt从xml生成可视化报告。 这样可以提供良好的可视化报告,同时仍然保留原始数据作为validation机制,如果需要的话。

在以前的公司,我们用XML和XSLT做了很多。 XML和XSLT都很大。

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

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

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

我个人喜欢XSLT,你可能想给简化的语法看一看(没有明确的模板,只是一个普通的旧的HTML文件,只有一些XSLT标签可以向其中添加值),但并不适合每个人。

也许你只是想给你的作者一个简单的Wiki或Markdown界面。 也有这样的库,如果XSLT不适合你,也许XML也不适合他们。

XSLT不是最终所有的XML转换。 但是,根据所给出的信息判断问题是否是解决问题的最佳scheme,或者是否还有其他更有效和可维护的方法,则很难进行判断。 你说作者可以用简化的格式input他们的内容 – 什么格式? 文本框? 你把它转换成什么样的html? 为了判断XSLT是否是正确的工具,这将有助于更详细地了解这种转换的特点。

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

XSLT 2.0包含了更多的string函数,但是我认为它不适合这种语言,XSLT 2.0的实现也不多。