为什么选择XSL转换?

XSLT是一种函数式编程语言,您可以使用它创建与任何模板系统一样丰富的前端。然而,你不应该这样做,你和你的团队会疯掉的。

这两个选项都提供了以逻辑方式将对象转换为表示形式的机会。XSLT最适合创建更多的XML,这可能会让您相信它是创建XHTML的完美候选者。但是,创建XHTML不应该是创建 是别担心这件事 中等的

XSLT的两个显著缺点与语法有关:您的模板及其包含的模板,以及这些模板包含的模板都将是庞大而冗长的。其次,您必须进行大量的函数式编程,经验较少的工程师在遇到递归模板时可能会感到困惑和恐惧,因为该模板具有累积的函数参数,而不是简单的for循环。

Google XML Pages ,并创建逻辑组织、类型安全的模板,这些模板将便于未来工程师学习和扩展。

大约5年前,我为一个企业产品创建了一个XML/XSLT驱动的UI。我们仍在使用它,现在回顾我的经验,我可以看到许多优点和缺点:

• XSL是一种功能强大的声明性语言,非常有用&对于经验丰富的开发人员来说,这很有趣,而转换只需几行代码就可以完成相当惊人的事情
• 上面这一点也赋予了您进行覆盖的能力。对于关联了A.xslt的类,我们可以轻松地将关联的模板切换到A-custom.xslt,这是对A.xslt的一些小更改和继承。我们可以在现场动态地执行此操作,好处是A-custom.xslt只需几行,而不是原始A.xslt的完整修改副本。占地面积小意味着它更有可能使用多个版本的A.xslt。
• 在.NET2.0中,XSLT被编译并变得非常快。Java可能也有类似的技术。(大多数模板语言现在也这样做。)
• XSLT在HTML&很好地处理转义、空白等问题

欺骗:

• XSL转换可能比“本机”模板慢。即使在编译时,XSL仍比大多数模板语言有更多的状态开销
• 如果您没有ObjectXPathNavigator或等效工具,那么在将数据对象转换为XML进行转换时会产生大量开销
• 根据转换器的功能,在转换为字符串缓冲区,然后将该字符串发送到输出设备时,也可能会产生缓冲开销
• XSLT的使用越高级,您的工具支持您的可能性就越小(特别是当您开始使用include或更快的方式来传递XML数据时)

希望有帮助!

我使用XSLT进行了重要的开发,在两个不同的站点上都取得了巨大的成功,但也完全失败了。

总结前的几点思考:

• 我认为没有人会认为XSLT比模板解析引擎强大得多,它是一种函数式语言。

• 尽管它不像大多数过程语言那样被广泛采用,但它仍然是一种实际项目中使用的真正的语言,人们可以雇佣已经具备XSLT知识的人员,而且对于您当前的员工来说,这是一种可转移的技能。

• XSLT也已经存在了一段时间了,实现已经成熟,我相信对于长时间运行的模板引擎(如Velocity)也是如此,但较新的引擎可能不那么健壮。

• 工具支持通常是非常好的。。。如果你有预算。XMLSpy和stylusstudio在过去对我都非常有用。

• XSLT不仅很难,更重要的是,它与众不同。大多数人不是受过函数式编程正式培训的计算机科学毕业生。大多数程序员将以过程式的方式编写XSLT,这不会利用该语言的任何功能,并且会给您带来维护方面的麻烦。

• XSLT转换可能很慢,并且占用大量内存。如果有一个带有大量XML输入的样式表,则可能会出现问题。

我喜欢XSLT,但您是否应该使用它归结为以下几点:

您是否致力于XSLT?您是否拥有XSLT方面的内部专业知识?你准备好了吗?

除非这些问题的答案是肯定的,而且你有复杂的数据,需要复杂的渲染过程,我不会考虑使用XSLT…尤其是在团队中没有经验的情况下。糟糕的XSLT比糟糕的模板糟糕得多。

走XSL之路将为您的应用程序提供未来证明。也就是说,如果您决定在将来添加更多具有不同布局的模板,您将能够利用这些优势。在我当前的项目中,我们保存了使用的XML(在XMLType或CLOB中),并允许其他应用程序通过web服务访问数据和XSL模板以生成文档。由于我们决定使用XML/XSL,最初的设计非常容易实现,这是经过深思熟虑的。

XSLT的优点是还可以生成其他文档类型(即pdf)的输出,现在很可能会生成pdf输出。XML/XSLT也将数据与视图分离。

然而,如上所述,XSLT语法和函数式编程思想会使有效生成模板变得困难。我们发现,我们喜欢坚持我们学到的技巧,当我们有客户的请求超出我们已经知道的范围时,没有人愿意自愿购买门票。通常,最终有人会想出如何完成任务,我们的“技巧袋”也会变得越来越大,但想出新的东西往往非常麻烦。

如果您没有预见到UI的任何变化,或者至少没有太多变化,那么XSLT可能不值得付出额外的努力。

请不要将XML/XSLT用于web前端。我参与过这样的项目,太可怕了。通常,您必须首先从对象或类似的东西生成XML,这是没有意义的。第二点是,有这么多优秀的HTML编辑器是免费的,但我发现没有一个是用于XSLT的。因此,编辑复杂的XSLT毫无乐趣。我建议使用HTML模板和通用模板引擎。

根据您的应用程序,有一个XML层,然后通过XSLT转换为XHTML,您可以在XML层编写简单的Web服务,允许您的客户使用您的站点数据。。。

我认为您需要检查数据的来源。正如boris callens前面提到的,如果要从数据库中提取数据,则必须首先转换为XML,然后应用转换。如果数据源是RSS或类似的,那么XSLT是一种自然的选择。

XPATH和XSLT具有很高的学习曲线,函数式编程可能会让人望而生畏。在时间紧迫的情况下,这可能不是正确的选择。

保持简单。这是一个人们越来越欣赏的原则。

Velocity或Freemarker的灵活性和通用性令人难以置信。您的代码库将是清晰的、易于理解的,并且运行速度将比X monstrosities快得多。

http://fishbowl.pastiche.org/2002/02/12/xslt_is_the_spawn_of_satan/

我知道如果您的数据已经是XML,XSL方法是多么方便。
但通常情况并非如此。它在数据库中的某个地方,需要当场生成或来自某个服务。

与HTML不同,如果您需要以任何方式对模板进行解析和处理,则有许多XML工具可用。因此,您应该选择XML来获得使用XML工具和库的好处。

然而,也就是说,XHTML可能正适合您的需要,因为它为您提供了对XML工具和库的全面支持,同时仍然是由现代web浏览器正确处理的普通HTML。如果以后需要对这些数据进行后处理,仍然可以对XHTML数据应用XSLT。

我使用了XML&XSLT在以前的项目“金融网站”中使用,它对我们很有效,但是:

1. 我们有多个客户 我们可以替换XSLT样式表 这使得网站发生了变化 开发人员更容易管理
2. 我们团队中有一位专业的网络编辑。我们给了他们一个示例XML&他们可以直接编辑样式表
3. 如果昨天网站上出现了任何措辞上的变化(这是一家银行,这种情况出人意料地经常发生),我们可以在不重新部署整个网站的情况下部署新的XSLT。
4. FOP 对于转换为PDF,它基于相同的技术,因此我们不难理解:-)

我看到使用XSLT的主要原因是,如果有多个站点都基于相同的XML,但需要不同的HTML输出。

XML+XSLT真的很酷。您可以在将来输出多种类型的目标格式。 但是ne意识到XML中嵌入了HTML。Firefox XSLT不支持“禁用输出转义”。看见 Bugzilla .

我们使用XSLT在我们的内容管理系统中生成html,它工作得很好。

话虽如此,如果您永远只需要一个布局,我怀疑您是否真的需要xslt。