我至今仍在继续开发它(实际上我现在应该在工作,而不是在SO上打游戏),我看到越来越多的东西使我认为放弃XSLT是一个明智的决定。
我知道XSLT有其存在的意义,因为它是一个被广泛接受的标准,如果每个人都在编写自己的解析器,其中90%的人最终会出现在TheDailyWTF上。但是,考虑到它是一个函数式语言,而不是大多数程序员熟悉的过程式语言,对于像我这样开始类似项目的人,你会推荐他们走我选择的道路,还是坚持使用XSLT?
我曾经广泛使用XSLT...大约几个小时。它很适合像更改元素名称或过滤输入文档(去除不需要的内容)这样的事情。
其他任何事情都会很快变得复杂。这种继承的复杂性加上大多数其他编程语言中所使用的大多数东西(如变量)的缺乏以及使XPath表达式难以阅读的简单方法,真的很痛苦。
最终,XSLT遭受了分裂:程序员不喜欢它,因为它有限制,而其他人根本无法使用它(比如网页设计师或任何其他非程序员类型)。
如果XSLT被推广为XML的某种SQL,情况可能会有所不同。首先,人们甚至不会费心去看它。那些看过的人也不会对痛苦感到惊讶。
我认为这个概念是可行的,也许执行起来并不像它本应该那样“干净”。
然而,我认为它应该被视为一种工具,可能不明智地在每个实例中使用它,但解决问题时永远不应忽略一个工具。
我见过非常好的XSLT,也见过非常糟糕的XSLT使用,我得出结论,其中一些可能取决于开发人员的技能。我认为这需要开发人员同时考虑多个领域。
它是未来吗?也许不是,也许有更好的解决方案...
我不知道什么新技术会出现,但至少学习它是最好的,增加自己的工具集肯定不是坏事吧?
我使用XSLT来纠正非常复杂的XML文件中的错误。因此,我使用XSLT来纠正XML中的错误,而不是处理它们。
这很棒。因为语言非常强大,而且它非常适合XML用例。 要在通常的编程语言中做同样的事情,需要花费很长时间来适应每次出现新的变化。
它还可以用于迁移Visual Studio解决方案,而不让Microsoft决定更改哪些内容。因此,将一个解决方案转换,检查发生了什么变化。还原您不想更改的内容,并在所有文件上运行执行工作的XSLT脚本。
因此,我从未使用它来制作Web演示文稿或类似的东西,但它有助于解决我的基于XML的问题。解决这些问题非常强大,值得一试。
我也曾经涉足过XSLT的世界,但有时候感觉有些棘手。我认为我的主要问题在于将“纯数据”XML转换成完整的HTML页面时存在困难。回想起来,也许使用XSLT生成一个页面片段,然后使用服务器端脚本(如SSI)将其与其他片段组合在一起,可以解决我的许多问题。
可能犯的一个错误是尝试构建一个通用的页面布局,通过使用document()函数导入XHTML或其他XML数据来包围我的数据。
另一个错误是尝试做编程性的事情,比如创建一个通用模板来生成基于XML数据的表格,其中逻辑会执行一些操作,例如对具有特定值的行使用不同的背景行颜色,并允许您指定要过滤掉的某些列。
更不用说尝试从XML数据中构造值的字符串列表,似乎只能使用递归模板调用才能解决。
那么我得到了什么?嗯,页面源代码就在那里,可供查看。数据和呈现被清晰地分离开来。
我会再这样做吗?可能不会,除非我真的想在一个静态页面上实现数据/展示分离。否则,我可能会编写一个Rails或Java EE应用程序,该应用程序可以使用模板生成XML视图或HTML视图 - 所有好处都在那里,但是我更自然(对我来说)的编程语言更容易上手。
我喜欢使用XSLT来改变XML文档的树形结构。但是,我发现它在处理文本方面有些繁琐,因此我会将这部分工作交给一个自定义脚本,在应用XSLT到XML文档之前或之后运行。
XSLT 2.0包含了更多的字符串函数,但我认为它并不适合该语言,并且也没有太多的XSLT 2.0实现。
我认为你做得很对。根据我的经验,XSLT开发人员是最难招聘的,因为它既没有被Web开发人员广泛采用,也没有被普通程序员所接受。
因此,你最终不得不支付“精通非主流语言的高级程序员”的溢价,但这种语言可能并不是该程序员最喜欢的。
我在使用XSLT方面有着不错的经验,但我并没有将其转换为HTML。可能XSLT-HTML组合对于完成任务来说非常困难。