【问题标题】:Browser rendering XSLT vs PHP rendering XSLT浏览器渲染 XSLT 与 PHP 渲染 XSLT
【发布时间】:2010-02-03 20:09:08
【问题描述】:

我在当前项目中使用 XML 和 XSLT,我想知道让浏览器使用样式表将 XML 渲染为 HTML 是否好,而不是使用 PHP xsltprocessor 之类的东西。

我使用 Browser xslt 处理器的一个主要原因是允许 API 在不久的将来访问我的 XML 数据。所以我想要转换客户端,所以我的 XML 仍然可用。

我可能对 PHP xsltprocessor 有误,但是当通过 PHP 处理 xml 时,接收到的数据是呈现的 XML(在我的情况下为 HTML),并且 XML 数据不再可用。对吗?

感谢您清理问题。

【问题讨论】:

    标签: xml browser xslt


    【解决方案1】:

    我建议在服务器端进行转换,因为您可以更好地控制它。如果您依赖浏览器,您可能会看到不同浏览器中的渲染引擎略有不同。如果您在服务器上转换并传递 html,那么您可以通过准确指定要生成的 html,确保该 html 的静态版本看起来正确,然后处理您的 XSLT 以确保它生成 html 来进行更清晰的测试正确。

    要在客户端获取可用的 XML,在转换的一部分中,您可以输出所需的 XML 部分(或整个 DOM),并将其放入 JavaScript 变量或页面上可访问的某个位置。

    我发现渲染客户端非常适合小型、受控(例如内部)使用,但对于您希望对输出服务器端进行严格控制的任何事情来说更可靠。

    【讨论】:

    • 我必须承认,我在使用 Browser XSLT Rendering 使 Javascript 在每个主要浏览器中工作时遇到了一些麻烦。但总体而言,HTML 以相同的方式呈现,所以我认为除了一些 Javascript 奇怪的行为之外,我仍然认为客户端转换不是一个糟糕的决定。有没有浏览器根本不支持?
    • 据我所知,所有浏览器都支持它,但您会在处理扩展功能或 XSLT 基础之外的任何内容方面遇到差异。它可能会正常工作,但您无法真正看到最终用户体验会是什么,所以这取决于对您来说有多重要。
    【解决方案2】:

    如果你用 MVC 模式设计应用程序,那没关系。您将能够通过 API 向常规浏览器和 XML 公开 HTML。

    即使您在服务器端执行 XSLT,如果/当您添加 API 时跳过该步骤应该相当简单。

    通常,客户端上的 XSLT 有很多缺点 — 延迟高,因为样式表和所有数据都必须在 anything 开始渲染之前完成加载。使用纯 HTML,您可以获得更低的延迟(只有一个文件,流式传输)并且甚至在 HTML 完成之前就开始下载其他资源。

    【讨论】:

    • 所以我猜它的高延迟与服务器运行时间相比。但是如果该样式表被浏览器缓存了呢?
    • 即使缓存了样式表,在 XSLT 开始生成页面之前,您仍然必须等到整个 XML 下载完毕。除非您的 XML 比 HTML 小得多(比较压缩后的大小!),否则它仍然较慢。
    【解决方案3】:

    这完全取决于您的最终目标是什么。我在一个以 xml 格式生成报告的应用程序上工作,我们将 xml 和 xslt 发送到浏览器以进行处理。这种方法有几个原因:

    • 正如您已经提到的,您可以在客户端上进行进一步处理
    • html 相当冗长,如果您可以控制指定 xml,则可以确保它不会那么冗长,因此最终您在服务器和浏览器之间发送少量数据
    • xslt 可以缓存在浏览器上,因此在第一次使用后不会产生开销
    • 在服务器上执行转换会增加服务器的负载,如果您有很多人试图同时访问该页面,这可能会产生影响。

    在某些情况下,我们会在服务器上进行转换。例如我们转换为 html 表格,然后更改 http 内容类型以将结果作为 excel 发送。

    【讨论】: