XSLT 是否值得投入时间？是否有任何实际的替代方案？

Question

我意识到关于这个主题还有一些其他问题，普遍的共识是使用您选择的语言来操作 XML。然而，这个解决方案不太适合我的情况。

一、项目范围： 我们想要开发独立于平台的电子学习，目前，它是一堆 HTML 页面，但随着它们的成长和发展，它们变得难以维护。 我们已经有大约 30 个模块，每个模块有 10-30 个 HTML 页面，并且这个数量一直在增长。

想法： 拥有一个 XML 文件 + 电子学习模块前的架构，然后生成一些 XSLT 文件，将 XML 处理到电子学习模块中。通过 XSLT 将 XML 转换为 HTML。

为什么： 我们希望能够灵活地轻松重新格式化内容 我意识到 CSS 在这里是一个可行的替代方案，特别是在视觉上改变外观和感觉，但我们可能需要比这更强大的功能，并尽可能重组页面。 如果我们决定以任何方式更改页面布局或功能，我猜更改“共享”XSLT 文件会比更新 HTML 文件更容易。

根据一些“参数”，我们可以输出截然不同的页面布局/结构，超出 CSS 的能力。 XSLT 可以采用 QueryString 参数吗？不确定..

现在，所有这些都必须独立于平台，并且能够“离线”运行，即没有服务器为 HTML 提供动力，因此服务器端技术是不可能的（C#，PHP

） XSLT 还远吗：

• 开销？不太清楚为什么......转换为 HTML 需要计算能力吗？
• 很难学习
• 更好的替代方案

现在，我想确切地知道的是：

• 对于这种“离线”实际上是否有任何可行的替代方案？
• 我是否以正确的方式处理这件事，
• 你们有什么建议或替代方案吗？

编辑： 无论有没有 XSL、CSS 和 JQuery 将是我们解决方案中非常突出的部分 发展。 一般整理（草率的英语！）

Answer 1

为此使用 XSLT 方案是合法的。如果您具备专业知识，XSLT 将会非常强大。

• 开销：是的，对于大型文档，转换可能需要几秒钟的时间。对大型文档进行每分钟调用多次的转换可能是一个糟糕的策略。这对您来说不会是一个大问题，因为您不会按需进行这些转换，而只是在您想要修改时进行。
• 很难学习。您很快就可以使用 XSLT 提高工作效率，但要注意：当 XSLT 看起来变得容易时，您会惊讶地发现它突然变得棘手！你认为困难的事情可能很容易，反之亦然。例如，您可能需要导入或创建一些模板来执行一些简单的日期格式设置。不过这一切都是可行的。不要害怕学习如何做“模板”。
• 更好的选择。是的，有更好的替代方案，但它们是特定于平台的。例如，我在 .NET 领域，我已经放弃了 XSLT，转而使用新的 XElement 等，并且 VB.NET 嵌入的 XML 非常强大且简单。但是，当您想避免依赖于特定平台时，XSLT 仍然很棒。

您仍然会使用 CSS 作为您策略的一部分，对吗？更改 XSLT 以一致地输出样式比手动在 30 个模块中完成要好，但是精心规划的 CSS 样式表仍然可以帮助简化事情（提高可维护性和灵活性）。

总结：组织静态 html 页面的布局/修订，独立于平台，灵活分发：是的，从我看来，你有一个很好的策略。您在 XSLT 方面积累的专业知识在将来也将很有用。掌握 XSLT 后，您将真正理解 XML，这将永远有帮助。

Answer 2

XSLT 是在您所描述的情况下用于从 XML 文档生成 HTML 的理想工具。如果您使用 XSLT 生成静态 HTML 页面，那么关于 XSLT 处理开销的常见抱怨（它需要将整个源 XML 文档加载到内存中）实际上并不重要，除非您可能生成数十万个页面。

（事实上​​，这种抱怨实际上只与源 XML 文档很大的情况有关。如果您已经构建了一个围绕从大型 XML 文档动态生成 HTML 的体系结构，那么选择 XSLT 作为您的技术可能是一个错误，但事实并非如此）这是一个大错误。）

当然，您也应该使用 CSS。

Answer 3

将数据与演示文稿分开。

将演示渲染卸载到浏览器，使用 CSS 和 CSS“增强器”，如 SASS、Less 等。

生成严格的 XHTML - 可以使用 CSS 格式化，可以使用 XML 解析器进行解析等。

使用 JQuery 等交互性

XSLT 相当重量级，不会扩展性很好，而 XHTML+XSS+JQuery 很好理解，并且存在很多工具。

Answer 4

如果您已经了解 C# 或 VB.NET，请考虑使用 LINQ to XML，代码会更长，但对于非 XSLT 专家来说，编写和维护可能会更轻松。

这一切都取决于您需要多少次 XML 转换，只要 1 或 2 次，我就不会花时间学习 XSLT。