Is XSLT worth it?前一段时间，我开始设计一个html风格的XML模式的项目，以便作者可以以简化的格式编写其内容(教育课程资料)，然后通过XSLT转换为HTML。我玩了一段时间(苦苦挣扎)，并将其提升到一个非常基本的水平，但是后来我因遇到的局限性(可能是我的知识局限性)以及阅读博客建议放弃时的局限而感到恼火XSLT并仅用您选择的语言编写您自己的XML解析器，我急切地跳上了它，它的表现非常出色。 直到今天，我仍在努力(实际上我应该现在就在研究它，而不是在玩SO)，而且我看到越来越多的事情使我认为放弃XSLT的决定是好人 我知道XSLT占有一席之地，因为它是一个公认的标准，而且如果每个人都在编写自己的解释器，则其中90％的结果将最终出现在TheDailyWTF上。但是考虑到它是一种功能样式语言，而不是大多数程序员都熟悉的过程样式语言，对于从事诸如我自己的项目的某人，您是否建议他们沿着我所做的道路发展，还是坚持使用XSLT？ ？ 如此消极！ 我使用XSLT已经有好几年了，并且真的很喜欢它。您必须意识到的关键是它不是一种编程语言，而是一种模板语言(在这方面，我发现它比asp.net / spit优越得多)。 XML是当今Web开发的事实数据格式，无论是配置文件，原始数据还是在内存中。 XSLT和XPath为您提供了一种非常强大且非常有效的方法，可以将数据转换为您可能想要的任何输出格式，从而立即为您提供将演示文稿与数据分离的MVC方面。 然后就是实用程序的功能：清除名称空间，识别不同的架构定义，合并文档。 与开发自己的内部方法相比，使用XSLT必须更好。至少XSLT是一个标准，您可以租用它，而且，如果这确实对您的团队来说是个问题，那么很自然的做法就是让您让大多数团队仅使用XML。 一个真实的用例：我刚刚编写了一个应用程序，该应用程序处理整个系统中的内存XML文档，并根据最终用户的要求转换为JSON，HTML或XML。我有一个相当随机的要求提供Excel数据。一位前同事在编程上做了类似的事情，但它需要一个包含几个类文件的模块，并且该服务器已安装了MS Office！事实证明，Excel具有XSD：3小时内对基本代码的影响最小的新功能。 我个人认为这是我职业生涯中遇到的最干净的事情之一，而且我认为所有显而易见的问题(调试，字符串操作，编程结构)都归因于对该工具的理解有缺陷。 显然，我坚信这是"值得的"。 XSLT的优点：
XSLT的缺点：
顺便说一句，获得程序行为的一种方法是将多个转换链接在一起。每一步骤之后，您都需要使用一个全新的DOM，它可以反映该步骤中的更改。一些XSL处理器具有扩展功能，可以在一次转换中有效地完成此操作，但是我忘记了细节。 因此，如果您的代码主要是输出而没有太多逻辑，则XSLT可以是表达它的一种非常简洁的方法。如果有很多逻辑，但大多数都是XSLT内置的形式(选择所有看起来很虚构的元素，并为每个输出等等)，这可能是一个非常友好的环境。如果您想一直思考XML，那么请尝试XSLT 2。 否则，我想说的是，如果您最喜欢的编程语言具有支持XPath的良好DOM实现并允许您以有用的方式构建文档，那么使用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的使用日趋深入-技术发布已经存在了很多年，而贸易发布也正在到那里)。这些文档需要处理(在这里想到DocBook到ePub)。 上面的人评论说脚本往往在60行以下，否则变得笨拙。如果确实变得笨拙，那么很有可能是编码人员并没有真正想到这一点-XSLT与许多其他语言完全不同。如果您没有这种想法，那将是行不通的。 这当然不是一门必死的语言(我得到的工作量告诉我)。现在，在Microsoft完成XSLT 2的(很晚)实施之前，这有点"卡住"了。但是从我的角度来看，它仍然存在，并且似乎还很强大。 我们将XSLT广泛用于文档之类的事情，并使一些复杂的配置设置可由用户维护。 对于文档，我们使用了很多DocBook，这是一种基于XML的格式。由于文件为纯文本格式，因此我们可以使用所有源代码来存储和管理文档。借助XSLT，我们可以轻松构建自己的文档格式，从而既可以以通用方式自动生成内容，又可以使内容更具可读性。例如，当发布发行说明时，我们可以创建类似于以下内容的XML：
然后使用XSLT(将以上内容转换为DocBook)，我们得到了不错的发行说明(通常为PDF或HTML)，其中错误ID自动链接到我们的错误跟踪器，错误按组件分组，并且所有内容的格式完全一致。通过查询我们的Bug跟踪器以了解版本之间的变化，可以自动生成上述XML。 我们发现XSLT有用的另一个地方实际上是我们的核心产品。有时，当与第三方系统接口时，我们需要以某种方式处理复杂HTML页面中的数据。解析HTML很丑陋，因此我们通过TagSoup之类的数据(会生成正确的SAX XML事件，从本质上让我们像正确编写XML一样处理HTML)来馈送数据，然后可以对它运行一些XSLT，以数据转换为我们可以实际使用的"已知稳定"格式。通过将该转换分离为XSLT文件，这意味着如果HTML格式发生更改，并且当HTML格式更改时，则无需升级应用程序本身，而是最终用户可以自己编辑XSLT文件，或者我们可以通过电子邮件发送它们是更新的XSLT文件，而无需升级整个系统。 我要说的是，对于Web项目而言，比今天的XSLT有更好的方法来处理视图方面，但是作为一种技术，XSLT肯定有用途。它不是世界上最容易使用的语言，但它肯定不会死，而且从我的角度来看，它仍然有很多良好的用法。 XSLT是声明性编程语言的示例。 声明性编程语言的其他示例包括正则表达式，Prolog和SQL。所有这些都具有很高的表现力和紧凑性，通常针对它们要完成的任务设计得很好并且功能强大。 但是，软件开发人员通常讨厌这样的语言，因为它们与更主流的OO或过程语言截然不同，以致于它们很难学习和调试。它们的紧凑特性通常使其很容易在不经意间造成大量损坏。 因此，尽管XSLT是将数据合并到表示中的有效机制，但它在易用性部门中却失败了。我相信这就是为什么它没有真正流行起来的原因。 我记得新发布标准时有关XSLT的所有宣传。围绕能够通过"简单"转换构建整个HTML UI的所有兴奋之处。 面对现实吧，它很难使用，几乎无法调试，而且速度通常令人难以忍受。最终结果几乎总是古怪而又不理想。 在有更好的方法来做事情的同时，与使用XSLT相比，我会更加烦恼。它仍然占有一席之地，非常适合简单的转换任务。 我已经广泛地使用XSLT(也包括XQuery)来做各种事情-在构建过程中生成C ++代码，从文档注释中生成文档，以及在必须与XML尤其是XHTML一起使用的应用程序中。尤其是代码生成器，在大约十二个单独的文件中散布了10,000行以上的XSLT 2.0代码(它做了很多事情-客户端头，远程代理/存根，COM包装器，.NET包装器，ORM-命名)一些)。我是从另一个不太了解该语言的家伙那里继承下来的，因此较旧的位子一团糟。但是，我们撰写的较新的文章大多保持理智和可读性，而且我不记得实现此目的有任何特殊问题。当然，这比为C ++做任何事情都难。 说到版本，使用XSLT 2.0绝对可以使您保持理智，但对于更简单的转换，1.0仍然可以。在它的利基市场中，它是一个非常方便的工具，并且从某些特定于域的功能(最重要的是，通过模板匹配进行动态分配)获得的生产力很难匹配。尽管XSLT的基于XML的语法令人生厌，但是LINQ to XML中的同一件事(甚至在具有XML文字的VB中)通常要长几倍。但是，由于在某些情况下首先不必要地使用了XML，因此经常会出现不必要的错误。 总结一下：它是一个非常有用的工具，可以放在一个工具箱中，但是它是一个非常专业的工具，因此，只要您正确地使用它并达到预期的目的，它就很好。我真的希望XSLT 2.0有一个适当的本机.NET实现。 我使用XSLT(因为缺少更好的替代方法)，但不用于演示，仅用于转换： 我编写了简短的XSLT转换，以对我们的maven pom.xml文件进行批量编辑。 我已经编写了一个转换管道，以从XMI(UML图)生成XML模式。它工作了一段时间，但最终变得太复杂了，我们不得不把它从谷仓后面拿出来。 我已经使用转换来重构XML模式。 我已经通过使用XSLT生成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描述符文件和站点地图的片段。 这不是万能药。在某些方面它做得很好，在某些方面它做得不好，就像编程的所有其他方面一样，这都是关于使用正确的工具完成正确的工作。这是一个非常值得在您的工具箱中使用的工具，但只有在适当时才应使用。 我绝对会建议坚持下去。特别是如果您使用的Visual Studio内置了XSLT的编辑，查看和调试工具。 是的，这是您学习时的痛苦，但是大多数痛苦与熟悉有关。学习语言时疼痛会减轻。
W3schools有两篇特别有价值的文章： 我曾经认为XSLT是个好主意。我的意思是个好主意。 执行失败的地方。 随着时间的推移，我发现的问题是XML编程语言只是一个坏主意。它使整个事情变得坚不可摧。具体来说，我认为XSLT很难学习，编码和理解。在功能方面之上的XML只会使整个事情变得混乱。在我的职业生涯中，我曾尝试学习过大约5次，但这并不持久。 好的，您可以"工具化"它-我认为这部分是它设计的重点-但这是第二个失败：市场上所有的XSLT工具，简直就是……废话！ 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 ++，但我还是会使用我认为对提高软件项目的长期生存能力有用的语言。 我将XSLT广泛用于自定义MVC样式的前端。该模型被"序列化"为xml(而不是通过xml serializaiton)，然后通过xslt转换为html。与ASP.NET相比，优点在于与XPath的自然集成以及对格式要求的严格要求(使用xslt推理文档结构比大多数其他语言要容易得多)。 不幸的是，该语言包含一些限制(例如，转换另一个转换的输出的能力)，这意味着它有时会令人沮丧。 不过，我认为，现在可以轻松实现，强行实施的关注点分离并不是我所看到的另一种技术-因此，对于文档转换，我仍然建议这样做。 我发现XSLT很难使用。 我曾经在与您描述的系统有些相似的系统上工作过。我的公司指出，我们从"中间层"返回的数据是XML，并且页面将以HTML形式呈现，也可能是XHTML，此外他们还听说XSL是XML之间转换的标准格式。因此，"架构师"(我的意思是指那些具有深刻的设计思想但显然从不编码的人)决定通过编写XSLT脚本(将数据转换为XHTML进行显示)来实现我们的顶层。 选择结果是灾难性的。事实证明，编写XSLT很痛苦。因此，我们所有的页面都难以编写和维护。如果使用JSP(这是Java语言)或其他类似的方法将输出格式(HTML)使用一种标记(尖括号)和另一种标记(例如<％... ％>)。关于XSLT的最令人困惑的事情是，它是用XML编写的，并且从XML转换为XML……很难完全记住所有3种不同的XML文档。 您的情况略有不同：无需像我一样在XSLT中编写每个页面，您只需要在XSLT中编写一位代码??(从模板转换为显示的代码)。但是听起来您可能遇到了和我一样的困难。我会说，像您一样尝试解释基于XML的简单DSL(特定于域的语言)并不是XSLT的强项之一。 (尽管它可以完成工作……毕竟，它已经完成了图灵！) 但是，如果您的工作更简单：您拥有一种XML格式的数据，并且想要对其进行简单的更改-不是完整的页面描述DSL，而是进行了一些简单明了的修改，那么XSLT就是一个出色的工具。声明性(而非过程性)本质实际上是为此目的的优势。 -迈克尔·彻姆赛德 XSLT很难使用，但是一旦您克服了它，您将对DOM和架构有非常全面的了解。如果您也是XPath，那么您将在学习函数式编程的途中，这将向您介绍解决问题的新技术和新方法。在某些情况下，连续转换比过程解决方案更强大。 XSLT规范将XSLT定义为"一种用于将XML文档转换为其他XML文档的语言"。如果您想做任何事情，但XSLT内最基本的数据处理方法可能都有更好的解决方案。 还值得注意的是，可以使用自定义扩展功能在.NET中扩展XSLT的数据处理功能：
我仍然相信XSLT很有用，但它是一种丑陋的语言，可能会导致可怕的无法阅读，无法维护的混乱。部分原因是XML对人类的可读性不足以构成"语言"，部分原因是XSLT处于声明性和过程性之间。话虽如此，而且我认为可以使用正则表达式进行比较，但在解决简单的定义明确的问题时，它很有用。 使用替代方法并在代码中解析XML可能同样令人讨厌，并且您确实希望使用某种XML编组/绑定技术(例如Java中的JiBX)将XML直接转换为对象。 我为公司维护一个在线文档系统。作者使用SGML(类似于xml的xml语言)创建文档。然后将SGML与XSLT组合并转换为HTML。 这使我们无需编写任何代码即可轻松更改文档布局。只需更改XSLT。 这对我们来说很好。在我们的情况下，它是一个只读文件。用户没有与文档进行交互。 另外，通过使用XSLT，您可以更接近问题域(HTML)。我一直认为这是个好主意。 最后，如果您当前的系统有效，请不要理会它。我永远不会建议破坏您现有的代码。如果我从头开始，我会使用XSLT，但在您的情况下，我会使用您所拥有的。 如果您可以声明性的方式使用XSLT(尽管我并不完全同意它是声明性语言)，那么我认为它很有用且富有表现力。 我编写了使用OO语言(在我的情况下为C＃)来处理数据/处理层但输出XML而不是HTML的Web应用程序。然后，客户端可以将其直接用作数据API，也可以由XSLT将其呈现为HTML。由于C＃输出的XML与该用法在结构上兼容，因此一切都非常顺利，并且表示逻辑保持了声明性。跟从C＃发送标签相比，跟踪和更改要容易得多。 但是，由于您需要在XSLT级别上使用更多处理逻辑，因此即使您"了解"了功能样式，它也会变得令人费解和冗长。 当然，这些天我可能已经使用RESTful界面编写了这些Web应用程序-我认为JSON等数据"语言"在XML传统上已经由XSLT转换的领域中越来越受欢迎。但是目前，XSLT仍然是一项重要且有用的技术。 它取决于您的需求。它的主要优点是转换的易维护性，编写自己的解析器通常会消除这种情况。话虽如此，有时系统很小却很简单，实际上并不需要"理想"的解决方案。只要您的基于代码的构建器是可替换的，而无需更改其他代码，就没什么大不了的。 至于XSL的丑陋，是的，它很丑陋。是的，这需要一些习惯。但是一旦掌握了它(不要花很长时间IMO)，它实际上就很顺畅。根据我的经验，编译后的转换运行非常快，您当然可以对其进行调试。 我以前使用过XSLT。这6个.xslt文件(从一个大文件中重构出来)的组大约需要2750行，然后才用C＃重写。目前，C＃代码为4000行，其中包含很多逻辑。我什至不想考虑在XSLT中编写什么内容。 当我意识到没有XPATH 2.0严重损害了我的进步时，我就放弃了。 我个人喜欢XSLT，您可能想看一下简化的语法(没有显式模板，只有带有几个XSLT标记的常规旧HTML文件，可向其中吐入值)，但这并不适合所有人。 也许您只想为您的作者提供一个简单的Wiki或Markdown界面。也有相应的库，如果XSLT对您不起作用，则XML也可能对它们不起作用。 我在XSLT上花费了很多时间，发现它虽然在某些情况下是有用的工具，但绝对不是全部。当它用于机器可读的XML输入/输出的数据转换时，它对于B2B而言效果很好。我不认为您在陈述其局限性时走错了路。使我最沮丧的一件事是XSLT实现的细微差别。 也许您应该看看其他可用的标记语言。我相信Jeff就有关堆栈溢出的主题做了一篇文章。 HTML是人道标记语言吗？ 我来看看他写了什么。您可能会找到一个"开箱即用"的软件，它可以满足您的要求，或者至少非常接近，而不是从头开始编写自己的东西。 我目前负责从公共站点抓取数据(是的，我知道)。值得庆幸的是，它符合xhtml，因此我可以使用xslt来收集所需的数据。最终的解决方案可读，干净，并且在需要时易于更改。完善！ 要回答您的三个问题： 我相信许多开发人员不喜欢XSLT的原因是因为他们不了解XSLT所基于的根本不同的范例。但是随着最近对函数式编程的兴趣，我们可能会看到XSLT卷土重来... 在以前的公司中，我们在XML和XSLT方面做了很多工作。 XML和XSLT都很大。 是的，这里有一个学习曲线，但是您就有了一个强大的工具来处理XML。您甚至可以在XSLT上使用XSLT(有时可能会有用)。 性能也是一个问题(对于非常大的XML)，但是您可以使用智能XSLT来解决此问题，并使用(生成的)XML进行一些预处理。 任何了解XSLT的人都可以更改成品的外观，因为它不是经过编译的。 xslt真正发挥作用的地方之一就是生成报告。我发现有一个两步过程，第一步将报告数据导出为xml文件，第二步使用xslt从xml生成可视报告。这样可以生成漂亮的可视报告，同时在需要时仍保留原始数据作为验证机制。 我也涉足XSLT的领域，我发现它在某些地方有些尴尬。我认为我的主要问题是难以将"纯数据" XML转换为完整的HTML页面。事后看来，也许使用XSLT生成可以与其他片段一起使用服务器端脚本(例如SSI)组成的页面片段，可能会解决我的许多问题。 可能的错误之一是尝试通过使用document()函数导入XHTML或其他XML数据来构建一个通用页面布局来包围我的数据。 另一个错误是试图做一些编程上的事情，例如创建一个通用模板以使用逻辑在XML数据上生成表，这样做是对具有特定值的行使用不同的背景行颜色，并允许您指定一些要过滤的列。 更不用说试图从XML数据构造值的字符串列表了，这似乎只能使用递归模板调用来解决。 我得到了什么？好吧，页面源是XML数据，可供查看者使用。数据和表示形式整齐地分开。 我会再做一次吗？除非我真的想要静态页面上的数据/表示分离，否则可能不是。否则，我可能会编写一个Rails或Java EE应用程序，该应用程序可以使用模板生成XML视图或HTML视图-所有的好处，但是对我来说，自然而然的编程语言就可以了。 我喜欢仅使用XSLT来更改XML文档的树结构。我发现做任何与文本处理有关的事情并将其委托给我可能在将XSLT应用于XML文档之前或之后运行的自定义脚本都是很麻烦的。 XSLT 2.0包含了更多的字符串函数，但是我认为它不适用于该语言，并且XSLT 2.0的实现并不多。
XSLT并不是xml转换的最终结果。但是，很难根据给出的信息来判断这是否是解决问题的最佳方法，或者是否还有其他更有效且可维护的方法。您说作者可以以简化格式输入内容-什么格式？文字框？您将其转换为哪种HTML？ 我认为您做对了。以我的经验，XSLT开发人员是最难雇用的人，因为它是Web开发人员和临时程序员从未使用过的一种语言。 因此，您最终不得不支付"了解主流语言之外的高级程序员"的费用，但要支付可能不是该程序员喜欢的语言的费用。 我在XSLT方面有相当不错的经验，但是我没有转换成HTML。 XSLT-HTML组合可能很难完成任务。 我需要在这里使用XSLT，因为有人认为解决一个给定的问题是个好主意：我们需要从多个XML文件中提取一些数据，并将它们连接到不同的输出格式中，以进行进一步的处理。 Fisrt我认为XSLT是一个很好的主意，因为它是您可以信赖的标准。对于不需要在代码中使用太多编程逻辑或算法的简单格式化任务而言，这是正确的。
但是：这是一条逐步学习的曲线，因为它不是程序性的。如果您习惯了过程式编程(C，Java，Perl，PHP等)，那么您将错过许多常见的结构，或者您会想知道那些只是笨拙的东西，有时甚至是未经培训的人无法真正理解的东西。 我遇到的主要问题是，到目前为止，有许多来自程序背景的人都在处理XSLT文件，并且几乎每个人都"模仿"了他的需求。 因此得出一个结论：我不再将XSLT视为"终极"解决方案。实际上，在XSLT中读取或编写某些构造很痛苦。对于大多数情况，您将不得不考虑该应用程序：对于简单的转换，我可能会再次使用XSLT。但是对于更复杂的软件，我将不再使用。 我认为是的。 有关XSLT的真正酷用法的一个很好的例子，请查看暴雪的魔兽世界。 http://www.wowarmory.com 就纯粹的生产力而言，最好使用jQuery风格的库之一-pyQuery，phpQuery等。大多数XML库很烂，而XSLT本质上只是封装为成熟语言的另一个XML库，但是没有一套不错的工具。 jQuery使使用您选择的语言遍历和操作XML样式数据变得异常容易。
XSLT 1.0是最可移植的代码之一，至少在台式机和服务器计算机上是如此。
这非常适合构建一些需要可移植性和轻量级/无需安装的应用程序。 另外，XSLT仅需要运行时(不需要编译器)，您可以使用任何文本编辑器来创建代码。因此，您可以从任何桌面轻松地创建程序(当然，一旦掌握了语言)。 我确实广泛使用XSLT ...几个小时。更改元素名称或过滤输入文档(将不需要的东西剥离掉)之类的东西很酷。 其他任何事情都会很快变得复杂。这继承了复杂性，再加上缺乏其他任何编程语言(如变量)所使用的大多数功能，以及使XPath表达式无法读取的简便方法，这确实很痛苦。 最终，XSLT遭受了分裂：程序员由于其局限性而不喜欢它，其他所有人根本无法使用它(例如，网页设计师或任何其他非程序员类型)。 如果将XSLT提升为XML的SQL，则情况会有所不同。首先，人们甚至都不会去研究它。而那些这样做的人不会为痛苦感到惊讶。 我认为这个概念是合理的，也许执行不像可能的那样"干净"。 但是，我认为应该将其视为一种工具，在每种情况下使用它可能都不是明智的选择，但是在解决解决方案时，切勿忽略该工具。 我已经看到了非常好的XSLT，也非常不好地使用XSLT，并且我得出结论，其中的一部分可能取决于开发人员的技能。我认为开发人员需要同时考虑多个领域。 是未来吗？也许没有，也许有更好的解决方案。 我不知道会出现什么新技术，但至少是最好的学习方法，增加自己的工具集肯定不是一件坏事吗？ 我使用XSLT来纠正非常复杂的xml文件中的错误。因此，我使用xslt来更正它们，而不是处理xml中的错误。
这很棒。因为语言是如此强大，并且适合xml用例。 在不让Microsoft决定更改哪些内容的情况下迁移Visual Studio解决方案也很有用。因此，转换一种解决方案。检查更改了什么。还原您不想更改的内容，并在所有文件上运行xslt脚本来完成该任务。 因此，我从未使用它来进行Web演示或类似的操作，但是它可以帮助我解决基于xml的问题。而要解决这些问题，它的功能确实非常强大，值得一看。 谈到互操作性，XML是信息存储的标准。大量工具会产生XML输出，与将浏览器嵌入应用程序并格式化XML并将其放入浏览器相比，有什么更好(或更容易)的方式来呈现它。 |
