20

我将整个站点转换为 XML/XSL，我想知道当前执行客户端 XSLT 的所有问题。

以下是我已经知道的（来自第一手经验）：

  • 跨域 XSL 文件（这是一个安全问题，而不是跨浏览器）
  • 禁用输出转义（这在 FF 中不起作用......他们认为这是一个安全问题）

至于浏览器支持，这就是我所知道的：

  • 歌剧 9+
  • 法拉盛 1.0+
  • SF 2.0 +（我可能错了）
  • 铬合金
  • IE 6.0 +

任何其他人也会有帮助:)

编辑：

至于第二个陷阱，有一个不错的解决方法，可以让您将 xhtml 传递给您的 xsl。它通过实际转换并确保您的 XHTML 是有效的 XML 并将其作为 XML 放入您的 XML 来工作。然后在您的 XSL 中复制 xml ;) 并将其输出为 XHTML。

4

5 回答 5

14

  • 速度：浏览器需要在呈现 HTML 之前应用 XSLT 转换，因此用户将不得不等待更长的时间才能看到页面。浏览器使用的 XSLT 引擎可能不是一流的。在 Mac OS X 上，浏览器可能会在转换 XML 时冻结并导致“旋转的沙滩球”光标，因此用户可能会敲击屏幕并伤害自己。

  • 可访问性：不在该集合中的浏览器（例如屏幕阅读器）呢？这些用户对你重要吗？

于 2009-05-08T18:56:41.607 回答
5

在性能方面......考虑到现在大多数客户端都有 2 个 CPU 和 2 GB RAM，而大多数服务器没有......每个客户端有两个 CPU + 2 GB。因此，卸载 XSLT 转换应该提高可伸缩性，缓存 CSS + XSLT + JS应该减少整体流量当然是合乎逻辑的。

话虽如此，我过去曾尝试使用 XSLT 生成包含 SVG 的 XHTML，但遭遇了史诗般的失败。最大的页面太大了（索引中有 3,000 多个条目），IE 使用 DOM 进行 XSLT 转换，这导致它开始垃圾。在 xerces-j（在服务器上，在同一个开发盒上）中完成的相同转换大约快 1000 倍。

现在是浏览器猴子使用该程序的时候了；-)

一个有趣的讨论。谢谢你提出来。

干杯。基思。

于 2009-05-17T08:14:47.470 回答
2

我发现将参数传递给 xsltfiles 很难保持交叉浏览的能力。我现在支持 FF 和 IE，但 Chrome 也因此退出了。

于 2009-05-08T19:03:42.497 回答
1

我在一个使用 xslt+xml-> html 的项目中工作了大约 1 年（尽管仅限于服务器端）

我遇到的主要缺点：没有适合 Web 开发的 xslt 生成的好工具。没有预览html。没有验证。由此产生的 xslt 完全是一团糟，没人能理解。这不是 xslt 设计者的错，而是 xslt 处理模型的结果。

xslt/xml/urls 之间的分层变得比应有的复杂。您无法进行面向组件的编程。

通常需要多个 xslt 文件，这将导致在客户端进行大量下载。否则会导致整个项目的大量代码重复。

i would see this as a form of early optimisation. you shoud start by using a "normal" web framework like wicket, jsf, tapestry, gwt etc.., later if it turns out your servers preformance is cpu-bound you might ocnsider rewriting the most often used parts of the apllication that way.

otoh, it has real benefits if you need to provide both an xml api + a html interface.

于 2009-05-17T15:01:08.947 回答
0

XSLT 文件是另一个需要下载的对象，浏览器只会并行获取 2 或 3 个项目。我的经验是整体性能（下载和生成）明显较慢。

此外，根据数据的复杂性和冗余性，您下载的内容可能比实际需要的多得多 - 即。如果 HTML 已经被渲染。

于 2009-05-11T08:56:40.807 回答