我是过去8年的开发人员。我们主要使用XSLT将XML转换为HTML。我们还将它用于XML到XML的转换。
但是我们现在可以替代所有东西。可以通过诸如ASP.Net之类的编程语言轻松地创建HTML。可以使用任何标准的高级语言来读取和处理XML。由于XSLT中的编程有些复杂,因此任何人都希望使用最新的编程语言。
现在我的问题是:如果不考虑维护已经开发的XSLT的事实,XSLT将来会是一个重要的选择吗?我可以推荐新的程序员学习XSLT吗?
<expletive deleted="true" />吗
我是过去8年的开发人员。我们主要使用XSLT将XML转换为HTML。我们还将它用于XML到XML的转换。
但是我们现在可以替代所有东西。可以通过诸如ASP.Net之类的编程语言轻松地创建HTML。可以使用任何标准的高级语言来读取和处理XML。由于XSLT中的编程有些复杂,因此任何人都希望使用最新的编程语言。
现在我的问题是:如果不考虑维护已经开发的XSLT的事实,XSLT将来会是一个重要的选择吗?我可以推荐新的程序员学习XSLT吗?
<expletive deleted="true" />吗
Answers:
在某些重要情况下,XSLT可能是一个不错的选择:
ETL(提取,转换,加载)软件在某些情况下可以使用XSLT。例如,当提取的数据和要加载的数据都为XML格式,并且可以在无需重新编译应用程序的情况下更改转换的位置时,这可能是一个不错的选择。
一些将数据存储为XML的应用程序使用XSLT以人类可读的格式显示此数据¹。例如,Windows Live Messenger将消息的踪迹存储为XML,但是当您在WLM本身中打开历史记录时,它将显示一个漂亮的表,实际上是通过XSLT构建的HTML。
如果打算以编程方式使用网站的页面,则某些面向开发人员或面向数据的网站可能希望提供对XML的访问权限²。这比使用HTML解析器更好,尤其是因为HTML代码可以随时更改。
XSLT在网站上使用时,允许严格区分HTML和后台代码,从而可以雇用一名代码后台开发人员和另一名HTML / CSS内容开发人员。请参阅我对另一个问题的回答中的第1点。
XSLT将来会是一个重要的选择吗?好吧,今天这不是一个重要的选择,我怀疑XSLT的使用会随着时间的推移而增加。我忽略了这个原因,但是许多开发人员不喜欢XML而讨厌XSLT。
您可以推荐新的程序员来学习XSLT吗?当然!不仅XSLT可以在某些情况下使用其他方法会变得更加困难,而且XSLT拥有一种其他语言所没有的非常特定的方法。
¹这就是说XML并不是人类真正可读的:如果您要求不从事IT工作的人阅读XML,他会感到恐惧。
²我知道有网络服务。但是有时候,在每个页面上构造一个动态对象,然后将其序列化为XML,然后通过XSLT将其转换为HTML,或者让该漫游器直接访问XML,有时更容易,更直接。
XSLT几乎已死,因为只有少数爱好者仍在使用它。但是,没有真正的替代方法。如果仅关注单个用例,例如从语义文档中呈现HTML页面,那么您会找到更好的工具。如果您正在寻找代码生成模板引擎,那么这里还有更好的工具。文件转换也一样。
但是,如果您要寻找一种在所有平台上都能很好地支持所有这些用例的工具,那么选择将非常有限。如果您已经有一个XML文档,并且必须将其转换为可以使用您的工具的格式,那么最好只使用XSLT(或XQuery)处理数据。
无论哪种方式,您都可以在几天甚至几周内学习XSLT。进行第一手体验不会伤害您。试一试。至少值得将这种模式(基于规则的转换)存储在脑海中以备后用。仅此一点就证明学习XSLT是合理的。
嗯,我想知道从代码创建HTML的高级API是否使用任何“幕后”的XSLT ...
在我致力于将XML从一种源格式转换为多种其他格式的过程中,XSLT被广泛使用。它也可以用于将XML转换为非XML输出。我还没有做很多事情,但是我听说它已经针对PDF和PostScript等进行了。
XSLT不是人类可读的。元信息(标签)在实际信息(文本,xpath请求)上占据了太多位置。一个好的代码应该看起来像一个文档,而XSLT并非如此。对于映射工具而言,这是一种很好的持久性格式。
良好的转换语言应允许预览转换结果并同时查看转换流程(IF,ELSE,FOR,WHILE)。这对于可维护性很重要。关于这方面Velocity或GenearateXY优于XSLT。GenerateXY甚至更好,因为它可以将预览和流程分开,而使用Velocity,您将不得不打破预览缩进以提供可读的流程。
XSLT的唯一优点是它通过使用甚至滥用“ xsl:template”元素来关心模块性。这样做的问题是,它对数据处理语言(Java,C,...)有好处,而对于表示语言却非常次要。
确实
有一天,某些东西可能会取代XSLT,因为学习和使用它有点麻烦。但是,目前还没有可用的模板/转换语言afaik在其实现中具有同样的灵活性和“纯粹性”。
XSL-T可以用于多种用途:
基本上所有这些都是相同的,但是,将一个XML数据文件转换为另一个。现在让我们看一下可以代替XSLT使用的一些不同工具。
如果我们想操纵一个XHTML页面的内容,我们可以使用regexp,但是regexp对于结构性的东西来说是混乱的。它对于操纵字符串很有用,但是我不会用它来为某些内容创建目录或以其他布局呈现它。
接下来是ASP.Net。我们将布局放在asp页面中,并在动态部分的后面插入一些代码。另一种选择是放弃布局部分,并从数据库生成所有内容,然后使用C#创建所需的输出。
第一种方法的问题在于,从描述性数据转换为实际内容很笨拙。如果您有一些包含电话号码的数据文件,并且要在每个字母的标题处显示,请显示条目总数nr等,您必须在布局文件中生成一些布局,并在生成的代码中拥有一些布局。另一种选择是使用某种形式的Web网格,我发现这些网格很杂乱,突然间,您必须了解当您想要做的就是在给定数据的情况下输出一些特定的html时,Frigging网格的工作方式。
完全动态化当然是一个选择,但这也很笨拙。即使在使用LINQ之类的最佳情况下,也必须以相当难看的方式将编程代码与输出混合在一起。此外,也没有适当的方法来正确处理html通常是的非结构化递归文档样式内容。
使用XSLT,您可以按原样或在其父项的上下文中为特定标签创建模板,因此,例如,如果它被其他东西作为父项,则呈现方式会有所不同。
一个漫长的漫长答案,但是是的,我认为描述性模板语言具有很大的价值,而XSLT是迄今为止获得的最好,最标准化的模板语言。
XSLT最大的失败是(在任何实际实现中)无法最小化一次为了高效处理而需要保留在内存中的文档数量。而是将整个文档读入某种形式的DOM表示形式,并对此进行处理。如果文档很大,那么内存要求也是如此。然而,许多样式表显然在任何给定时间都只需要当前标签和其他一些标签(例如,标签的祖先),因此可以用最少的内存和高效的流处理进行处理。
是的,就语言而言,这很奇怪,但这只是进入的障碍。如果您知道XSLT,它通常比替代方法要容易-但是,如果您将拥有大型文档(或一次要处理大量文档),则XSLT的内存影响通常会强制采用其他更耗时的替代方法。