不久之前,我开始创建一个项目,我设计了一个html-esque XML模式,以便作者可以用简化格式编写他们的内容(教育课程材料),然后通过XSLT将其转换为HTML.我玩了一段时间(挣扎)了一段时间并把它带到了一个非常基本的水平,但后来因为我遇到的限制(这可能是我的知识的局限性)太烦恼了,当我读到一篇建议要沟通的博客时XSLT,只需用你选择的语言编写自己的XML-to-any解析器,我就急切地跳到了它,并且它的运行非常出色.
到目前为止我还在努力(我实际上应该正在努力,而不是在SO上玩),我看到越来越多的东西让我觉得放弃XSLT的决定是一个好的.
我知道XSLT有它的位置,因为它是一个公认的标准,并且如果每个人都在编写自己的解释器,其中90%将最终在TheDailyWTF上.但鉴于它是一种功能风格的语言,而不是大多数程序员熟悉的程序风格,对于那些开始像我自己这样的项目的人,你会建议他们沿着我做的路走下去,或者用XSLT坚持下去？
这么多的消极性!
我已经使用XSLT好几年了,真的很喜欢它.你必须意识到的关键是它不是一种编程语言,它是一种模板化的语言(在这方面我发现它无可比拟地优于asp.net/spit).
XML是当今Web开发的事实上的数据格式,无论是配置文件,原始数据还是内存reprsentation.XSLT和XPath为您提供了一种非常强大且非常有效的方法,可以将数据转换为您可能喜欢的任何输出格式,立即为您提供将表示与数据分离的MVC方面.
然后是实用程序功能:清除命名空间,识别不同的模式定义,合并文档.
它必须是更好地应对XSLT比开发自己的内部方法.至少XSLT是一个标准,你可以雇佣的东西,如果它对你的团队来说真的是一个问题,它的本质就是让你的大部分团队只使用XML.
一个真实世界的用例:我刚刚编写了一个应用程序,它在整个系统中处理内存中的XML文档,并根据最终用户的请求转换为JSON,HTML或XML.我有一个相当随机的请求提供Excel数据.一位前同事以编程方式做了类似的事情,但它需要一些类文件的模块,并且服务器安装了MS Office!原来Excel有一个XSD:新功能,3小时内基本码影响最小.
就我个人而言,我认为这是我职业生涯中遇到的最干净的事情之一,我相信所有这些明显的问题(调试,字符串操作,编程结构)都归结为对该工具的错误理解.
显然,我坚信这是"值得的".
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更简单的输入格式.
我不得不承认这里存在偏见,因为我教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的实现.但它仍然存在,从我的观点来看似乎变得强大.
我们广泛使用XSLT来处理文档等内容,并使一些复杂的配置设置可由用户使用.
对于文档,我们使用了很多DocBook,这是一种基于XML的格式.这使我们可以使用所有源代码存储和管理我们的文档,因为文件是纯文本.使用XSLT,我们可以轻松构建自己的文档格式,允许我们以通用方式自动生成内容,并使内容更具可读性.例如,当我们发布发行说明时,我们可以创建类似于以下内容的XML:
Error when clicking the Foo button Crash at startup when configuration is missing Error when clicking the Bar button
然后使用XSLT(将上述内容转换为DocBook),我们最终得到了很好的发行说明(通常是PDF或HTML),其中错误ID自动链接到我们的错误跟踪器,错误按组件分组,并且所有内容的格式完全一致.并且可以通过查询我们的错误跟踪器来自动生成上述XML,以了解版本之间的变化.
我们发现XSLT有用的另一个地方实际上是我们的核心产品.有时,当与第三方系统连接时,我们需要以某种方式处理复杂HTML页面中的数据.解析HTML很难看,所以我们通过类似TagSoup(生成适当的SAX XML事件,基本上让我们处理HTML就好像它是正确编写的XML)来提供数据然后我们可以对它运行一些XSLT来转换将数据转换为我们可以实际使用的"已知稳定"格式.通过将转换分离为XSLT文件,这意味着如果HTML格式发生更改,则不需要升级应用程序本身,而是最终用户可以自己编辑XSLT文件,或者我们可以通过电子邮件发送它们是一个更新的XSLT文件,不需要升级整个系统.
我想说,对于Web项目,今天有更好的方法来处理视图端,而不是XSLT,但作为一种技术,XSLT肯定有用.它不是世界上最容易使用的语言,但它绝对不会死,而且从我的角度来看仍然有很多好的用途.
XSLT是声明性编程语言的一个示例.
声明性编程语言的其他示例包括正则表达式,Prolog和SQL.所有这些都具有高度的表现力和紧凑性,并且通常设计得非常好,并且对于它们的设计任务非常有用.
但是,软件开发人员通常讨厌这些语言,因为它们与更主流的OO或过程语言有很大不同,因此很难学习和调试.它们的紧凑性通常使得很容易在不经意间造成大量伤害.
因此,虽然XSLT是一种将数据合并到表示中的有效机制,但它在易用部门中失败了.我相信这就是为什么它没有真正流行起来.
我记得新标准发布时围绕XSLT的所有宣传.所有令人兴奋的是能够使用"简单"转换构建整个HTML UI.
让我们面对它,它很难使用,几乎不可能调试,通常是无法忍受的缓慢.最终结果几乎总是古怪而且不太理想.
我会更快地啃掉自己的腿而不是使用XSLT,而有更好的方法可以做.它仍然有它的位置,它有利于简单的转换任务.
我已经广泛地使用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实现.
我使用XSLT(缺少更好的替代方案),但不用于演示,仅用于转换:
我编写了简短的XSLT转换来对我们的maven pom.xml文件进行批量编辑.
我编写了一个转换管道,用于从XMI(UML Diagram)生成XML Schema.它工作了一段时间,但它最终变得太复杂了,我们不得不把它带到谷仓后面.
我使用转换来重构XML Schema.
我已经解决了XSLT中的一些限制,通过使用它来生成XSLT来完成实际工作.(曾经尝试编写一个使用命名空间生成输出的XSLT,这些命名空间直到运行时才知道吗？)
我一直回到它,因为它比我尝试过的其他方法更好地绕过它处理的XML,这似乎是不必要的有损或者只是误解了XML.XSLT很不愉快,但我发现使用Oxygen使它变得可以忍受.
也就是说,我正在调查使用Clojure(一个lisp)来执行XML的转换,但我还没有足够的知识来知道这种方法是否会给我带来好处.
我个人在完全不同的环境中使用XSLT.我当时正在处理的计算机游戏使用了大量使用XML定义的UI页面.在发布后不久的主要重构期间,我们想要更改这些XML文档的结构.我们使游戏的输入格式遵循更好的模式感知结构.
XSLT似乎是旧格式翻译的完美选择 - >新格式.在两周之内,我有数百页从旧到新的转换.我还能够使用它来提取有关UI页面布局的大量信息.我创建了嵌入了哪些组件的列表,其中我使用XSLT写入我们的模式定义.
此外,来自C++背景,它是一种非常有趣和有趣的语言.
我认为,作为将XML从一种格式转换为另一种格式的工具,它非常棒.但是,它不是定义将XML作为输入并输出Something的算法的唯一方法.如果你的算法是足够复杂,但事实上,输入是XML变得无关紧要到您选择的工具-即推出自己的C++/Python的/不管.
具体到您的示例,我认为最好的想法是创建您自己的XML-> XML转换,遵循您的业务逻辑.接下来,编写一个XSLT翻译器,它只知道格式化并且不会做任何巧妙的事情.这可能是一个很好的中间地带,但这完全取决于你在做什么.在输出上安装XSLT转换器可以更轻松地创建替代输出格式 - 可打印,适用于手机等.
是的,我经常使用它.通过使用不同的xslt文件,我可以使用相同的XML源创建多个多语言(X)HTML文件(以不同方式呈现相同的数据),RSS提要,Atom提要,RDF描述符文件和站点地图的片段.
这不是灵丹妙药.有些事情做得很好,事情做得不好,就像编程的所有其他方面一样,所有关于使用正确的工具来做正确的工作.这是一个非常值得在您的工具箱中使用的工具,但它应该只在适当的时候使用.
京公网安备 11010802040832号 | 京ICP备19059560号-6 