使用XSLT(XML样式表语言转换)从未见过互联网热潮期间出现的许多其他语言的普及.虽然它正在使用中,并且在某些情况下由大型成功公司(即暴雪娱乐公司)使用,但它似乎从未成为主流.你为什么认为这是？
Chu*_*uck 25
一个问题是XSLT 看起来很复杂.任何开发人员都应该能够学习语言结构,因为大多数其他语言都有类比.问题是构造和数据看起来完全相同,这使得难以区分使得XSLT比其他语言更难以阅读的两者.
第二个问题是它的用途比其他语言更有限.XSLT非常出色; 在XML上进行复杂或激进的转换.但它并不适用于与其他语言一样多的问题,所以它没有那么多使用.
第三,许多编程语言都有自己的用于转换XML的库.大多数情况下,使用XML时,只需要进行小的更改或查找.XML也可能是由开发人员已经用另一种语言编写的程序生成或使用的.这些因素意味着使用语言的内置实用程序更方便.
所有这些问题导致的另一个问题是惯性.也就是说,人们不知道它,他们没有看到他们对它有太多需求,所以如果有另一种选择,他们会避免将其作为解决方案.
您最终得到的是一种语言,它是许多开发人员在创建解决方案时的最后选择.XSLT很可能甚至被避免,因为它将成为工作的最佳工具.
在我看来,标准XSLT中最烦人的事情之一(我说的是XSLT 1.0,因为这是我用过的唯一版本)是它缺乏对字符串转换和一些基本日期时间函数操作的支持.
我无法理解的一件事是为什么像translate()这样的函数被设计并实现到xpath中,其他更有用的函数,如replace,to_lower,to_upper,或者 - 让我们疯了 - 正则表达式不是.
对于除Microsoft的MSXML以外的解析器,使用eXSLT(扩展的xslt？)来解决其中一些问题.我说我猜是因为我实际上从未使用它,因为它被声明与MSXML不兼容.
我不明白为什么XSLT 1.0的设计原理是"文本"操作不在语言范围内,因为很明显无论何时转换文件都无法避免这些字符串转换问题(例如:转换为法语格式为美国格式的非正式填充日期,2008年1月31日至2008年1月31日)呵呵......
通过允许使用JScript函数扩展XSL,这些文本操作问题通常非常基础并且很容易在MSXML中解决:您可以调用JScript函数来执行某些处理,就像调用任何XSL模板一样,但我总是发现该解决方案不优雅且最终创建了自己的XSL模板库.首先是因为JScript方式破坏了您的XSL可移植性,然后因为它迫使您混合编程逻辑:纯XPath/XSLT表达式中的一些位以及使用JScript的DOM /对象表示法中的其他位.
没有可更新变量是另一个对新手来说非常混乱的限制,有些人只是没有克服这个并继续挣扎.在一些简单的情况下,您可以使用混合的paremetrized模板和递归调用(例如实现增加或减少计数器)的变通方法,但让我们面对它,递归并不是那么自然.
我想我听说XSLT 2.0规范中已经解决了所有这些限制,遗憾的是MS决定不实现它并改为推广XQuery.那很难过,为什么不实施这两个呢？我认为XSLT仍然很有可能变得像CSS一样受欢迎.当你想到它时,学习XSLT最困难的部分是XPath,其余的并不像理解CSS中的级联行为那么困难,CSS已经变得如此受欢迎......
因此,在我的观点中,缺少所有这里提到的小事以及在XSLT 2.0中使用它们的时间(甚至MS都不支持它)导致了这种不受欢迎的情况.我希望MS毕竟决定实施它......
小智 5
因为大多数 XSLT 实现都具有较高的内存占用量（我认为这是由该语言的设计造成的），因为人们倾向于滥用 XSLT 来完成它并不特别适合的各种事情，以及 XSL 的纯声明性本质这使得某些类型的转换变得相当困难。
小智 5
它对于 xml 很有用，但对于典型的编码则不太好。它缺乏典型的基本概念（即可变变量），并使本应简单的事情变得非常复杂（或不可能）。它的大部分问题源于这样一个事实：xml 是一种出色的数据表示语言，但不是一种出色的编程语言。话虽这么说，我每天都使用它，并会在有意义的地方推荐它。与外部名称空间结合使用，它可以变得更有用（调用 java 等）。最后，这是另一种需要学习的语言，许多程序员更愿意坚持使用他们习惯的语言或类似于他们习惯的语言。
小智 5
因为使用 Java、C#、JavaScript 等来反序列化 XML 流、转换它并导出所需输出的代码更容易编写和维护，并且 XSLT 没有提供实质性的性能优势。
XSLT 使某些事情变得简单，但也使其他事情变得非常非常困难。