XSLT是Web框架的不错选择吗？

Question

我一直认为XML（以及之前的SGML）数据是魔鬼的格式。我是旧数据库和平面文件学校。尽管如此，我们正在开发一种商业化的网络产品，其框架基于链式翻译/转换XML数据。

由于我们正在采访职位以及与潜在客户交谈，他们喜欢这样做的概念，但是厌倦了长期支持XSLT 。有人甚至称之为众所周知的“死”。像COBOL，Unix和C一样死了，或像 Apple Business BASIC 那样死了？

无论如何，我很好奇，如果在XSLT上构建一个Web框架对公司来说真的不够（奇怪）。 是否存在固有的XSLT实施问题，这使得这项风险值得重新考虑？

Answer 1

现有基于XSLT的Web内容管理系统（如Umbraco和Symphony（SharePoint已在此处提及）的普及提供了有关XSLT适用于Web框架的良好证据。

如果有的话，XSLT正在上升。很高兴看到成熟的XML解决方案公司仍然在数量上采用它，例如，MarkLogic不久前为其XML数据库产品添加了XSLT功能。

W3C XSLT-3.0 Recommendation于2017年6月发布，显示了对XSLT未来的持续兴趣和投资。

还有一些用于XSLT（和XQuery）的有用的新开放标准扩展，例如EXPath项目，其功能库包括广泛的HTTP和Zip功能。

[更新] 随着Saxon-CE（现在是开源）的推出，XSLT 2.0处理现在可以在服务器端和客户端完成。它还可能为以前仅限于XSLT 1.0的框架提供2.0功能。

Saxon-CE中的语言扩展意味着XSLT模板现在可以使用简单的XPath和“事件模式”绑定到用户事件，并且在需要时还有更好的JavaScript互操作性。

Answer 2

有趣的是，SharePoint 2010已经完全采用了XSLT。 XSLT有腿......不要害怕。

Answer 3

我使用了一个内部框架，它依赖于XSLT来生成它的所有HTML（以及可怕的RTF和其他格式），这让我对这个主题有了一些相当强烈的意见。

XSLT是一种很好的语言，可以将一种XML格式转换为另一种格式，并且两者都有明确定义。

如果您的源数据是XML，那么将它转换为XHTML片段很方便，但是当您开始迷失模板引擎区域时，事情开始变得有些混乱。

与所有内容一样，它只是一个工具，如果你使用它的擅长它会很好用，如果你在每个机会使用它，你可能会滥用它，如果你用它来生成RTF文件你'犯下自然罪。

Answer 4

如果您的应用程序依赖于转换XML数据，那么这就是XSLT专用的内容，除了代码可能非常冗长之外，它的工作做得还不错。

我从来没有真正听到有关SAXON作为XSLT实现的问题的抱怨。

考虑到SXML，SXSLT，SXPath等等，值得考虑。

至于XSLT已经死了，我注意到它还在攀升，并没有真正超越它的峰值，虽然我注意到有更多的声音开始看到XML中的设计缺陷，但用作数据存储格式的XML是一个不寻常的决定，XML是一种很好的数据 - 表示格式，特别是在网络上，作为一个传输信息的容器也很冗长，但它可以提供信息。

XML确实有些人称之为设计缺陷。

Answer 5

XSLT是一组将树转换为另一棵树的规则。要有效地使用它，你应该这样考虑它。

XSLT对我的一些好处：

1. 我可以依赖的每个HTML编码器都可以编写XSLT转换（我可以很容易地将HTML编码外包），但是很少有人能够轻松处理ASP.Net控件，Mako模板，Django，JSP， Smarty模板和其他引擎同时使用。
2. 正确使用XSLT是自给自足的。我可以为HTML编码器提供输入XML，协商XSLT处理器，并开发与应用程序本身分开的XSLT转换。
3. XSLT环境是沙盒，HTML编码器几乎无法自己打开安全漏洞。
4. XSLT未绑定到XML：您可以编写自己的适配器以将数据传递到XSLT并注册自己的输出处理程序。但这不是基于libxslt（php，python）的解决方案的选项。

但这意味着，你不应该打破灵活性。当行为中有很多副作用的复杂实例传递给Saxon转换并且输入树仅用于启动进程时，我确实看到了环境。没有办法与复杂的应用程序服务器分开开发，只需要将样式表部署5分钟，看看输出是否正确。

UPD ：我的一些最佳做法：

正如我所说，主要的是将XSLT转换分开。 Libxslt + exslt，msxsl + native扩展等应该足以进行转换。如果XSLT缺少一些电动工具，我更喜欢在调用代码中执行它并传递给输入树中的transfromation。

应用程序应该构建可预测（记录）结构的XML（或树）。对于我感兴趣的每个页面：

1. 我生成一个XML（或者如果它不容易获取则手动编写）;
2. 准备生成的HTML，我将作为单独的静态文件获取;
3. 定义一个XSLT转换（从几个页面可能相同）。

然后我将所有内容都放在VCS中并创建一个批处理文件，以便将相应的XSL应用于每个XML，这样结果就会覆盖静态HTML文件。

现在运行svn diff html-folder（或类似的）会告诉我是否有任何转换破坏了HTML，以及确切的位置。我在XSL中进行了更改，然后再次运行批处理。一旦HTML相同，我就会提交。

XML文档结构中的每个更改都应该导致更新相应的XML和XSLT，以便HTML保持不变。每次请求的HTML更改都应导致XSLT中的相应更改。 HTML编码器可以孤立地工作，我可以看出是否有任何问题。

我使用XSLT的应用程序中的页面通常接受像showinput = 1这样的GET参数来返回没有应用转换的裸输入树，这样我就可以保存它并作为另一个特殊情况添加到VCS。 / p>

让我知道缓存，当我需要它时，我通常会缓存准备好的HTML页面。经常更改页面部分会加载客户端脚本。

Answer 6

它没有什么问题......

但是根据你所做的事情，它可能无法为你提供足够的钩子来做你想做的事情。

Answer 7

如果您担心客户是否不愿意维护XSLT（即使XSLT是标准的并且是XML转换的广泛采用的技术），您是否需要将您的产品专门用于XSLT以进行XML转换任务？如果可以（并且无痛）在框架中抽象出适当的XML转换/转换部分（即XML→XML输出），也许你可以允许不同的实现来执行相同的任务;不只是XSLT，而是XQuery，Java（SAX + DOM），无论......

如果您决定放弃“魔鬼的格式”并采用别的东西，这样的设计甚至可能是有益的; - ）

编辑：撇开，但你知道XProc吗？