有使用客户端 XSLT 的大型网站吗？答案

【问题标题】：Any big sites using Client Side XSLT?有使用客户端 XSLT 的大型网站吗？
【发布时间】：2010-09-21 10:01:27
【问题描述】：

最近，我一直在思考在服务器端构建原始 XML，然后在客户端使用 XSLT 样式表将 XML 转换为完整 UI 的某种非主流架构。当然，如果客户端不支持客户端 XSLT，则必须存在一种回退机制，在这种情况下，我们只需在服务器端为它们进行转换。

我对 XSLT 已经非常熟悉了，这种方法似乎将表示和内容完全分离，完全将数据强制转换为 XML，并使用 XSLT 进行表示。

我也知道这确实给应用程序增加了一层额外的复杂性，这只是另一个可能失败的移动部分。

我的问题是：是否有任何大牌或大流量网站使用这种方法，如果有：您从中吸取了哪些限制/经验教训？

感谢互联网，扎克

【问题讨论】：

两年后——你还在使用这种技术吗？
不，我不是。随着一堆新的（移动）设备的出现，这还不足以保证它能够正常工作。看起来魔兽世界也没有在使用这个。
他们可能刚刚将它从客户端移动到服务器端。
这当然也不是您可以检测到的类型，因为客户端 XSLT 测试失败意味着您需要重新加载整个页面才能执行转换服务器端。

标签： xml xslt frameworks

【解决方案1】：

就像其他人提到的那样，暴雪有许多客户端 xsl 网站。我建议避免使用客户端 xsl。这是一个非常酷的想法，但是您需要解决许多不寻常的错误。

在 Firefox 中，任何使用 document.write 的 javascript 都会破坏 DOM。此外，firefox 的 noscript 插件会停止客户端 xsl。在这两种情况下，用户都看不到任何东西。似乎没有办法检测到这种错误，所以回退是行不通的。

在 IE 中，如果您有任何 30 倍重定向到不同来源的东西（从 http 到 https 或跨子域），您将收到违反 same origin policy 的错误。你并没有真正违反同源政策，但 IE 的行为就像你一样。例如，如果您转到http://foo.example.com/login 并执行 302 重定向到 https://bar.example.com/login.xml，IE 会将 xsl 视为来自 bar.example.com 并将 xml 视为来自 foo.example .com。因此，您需要为重定向恢复元刷新等内容。

这些都是我不经意间想到的。这是个好主意，但请注意这些问题。

【讨论】：

有趣，不知道那个。不过，这些都是极少数情况。我觉得客户端 XSLT 是未来。将模板交给浏览器并让它们填充数据是互联网的工作方式。我喜欢暴雪在他们的大多数网站上使用它:)。但就像任何客户端一样......存在浏览器兼容性问题（css，js......）
您是否知道这些错误是否在 IE9 和 FF4 中仍然存在？
我不明白。 document.write 和同源策略与 xslt 有什么关系？这些是 JavaScript 问题。
lightblade，同源策略也适用于客户端xslt。按照我的理解，document.write 会破坏 DOM 并将其替换为 document.write 调用的内容。我在尝试使用一些 JavaScript 库时经常遇到这个错误。 JavaScript 和 xslt 都在 DOM 上运行。

【解决方案2】：

我无法详细告诉你它是如何实现的，但是World of Warcraft 的流量很大，而且他们的网站是按照你描述的那样实现的。

【讨论】：

你可以自己查看实现细节：worldofwarcraft.com/new-hp/layout/layout.xsl
尝试进入 Safari 中的页面，然后查看源代码。它不使用顶级节点，而是使用。样式表序言还在，Safari 是否显示转换的输出？
@zachleat：WoW 站点使用 UA 切换来确定是提供带有样式表指令的 XML 还是预转换的 HTML。 IIRC，只有 IE6+ 和 FF2+ 提供 XML。
确实，暴雪的网站就是这样做的。不幸的是，它在 IE6、7 和 8 中效果不佳，因为 MSXML 在应用 XSLT 时容易挂起和死锁。到目前为止，该问题仅在 Win7 中得到修复。

【解决方案3】：

我不知道有任何大型公共网站使用客户端 XSLT 转换（好吧，除了 Joel 提到的魔兽世界 :-)。所以我不能直接回答你的问题。

但是，有时我自己也在思考同样的问题，并且我有一个假设，即互联网上此类网站的数量必须非常接近于零。 :-)

我的这个假设背后的理论的简短版本是这样的：除了一些非常奇特的情况外，提供客户端 XSLT 选项根本不值得麻烦。 :-)

【讨论】：

【解决方案4】：

我在 2001 年工作的公司发布了一款服务器产品，该产品完全实现了您描述的架构。我们非常成功地将处理卸载到客户身上。此外，使用 HTTP 用户代理进行客户端检测，我们能够使用服务器端 XSL 处理来满足非常特定的客户端，例如日本手机。我认为使用这种技术的网站/服务/产品对客户来说非常透明。但是，我认为最近的趋势是在服务器端进行处理，这样您就不必依赖或测试针对各种客户端的特定 XSL 实现，并且您可以获得对某些您无法实现的 XSL 扩展的支持在支持绝大多数浏览器时使用。

我知道我并没有直接回答您命名一些知名网站的问题，但我希望我能为这个问题提供一些有价值的东西。所以，基本上我的观点是，除非进行模板处理所节省的性能比必须进行 QA、支持和开发三四个没有扩展的浏览器更有价值，否则你应该坚持使用服务器端处理。

【讨论】：

【解决方案5】：

我目前正在使用客户端 XSLT 运行一些小页面，不过都是瑞典语（lillemanfestivalen.se、resihop.nu 和 beta 项目）。我最担心的是谷歌没有索引我的页面内容，只是没有转换的 XML。然而，自从我一周前启动了 resihop.nu，它就出现在了 google with 转换中！ :D

现在我的另一个问题是 facebook 和其他社交网站，它们不知道如何处理它。然而，我仍然认为有利的一面大于不利的一面。我得到的惊人的速度和分离是可怕的。对于 resihop.nu，我什至不开发单独的 API，我只是将开发人员指向该站点本身。（不过需要做更多的工作才能让它变得更好）

【讨论】：

我现在用客户端 XSLT 推出了一些更大的网站。似乎谷歌在找到它时实际上对此进行了严厉打击。 :(

【解决方案6】：

我同意以利亚的回答。我认为使用客户端 XSLT 是一项艰巨的工作。你必须为此做很多质量检查。但是，对于服务器端，您不需要进行 QA。在使用客户端时，您必须照顾所有类型的客户端和可能性。在使用客户端 XSLT 时，您的代码可能会中断。

【讨论】：

【解决方案7】：

当我这么说时，我可能有偏见，但是在基于 Web 的应用程序上工作，我讨厌它。它甚至可行的唯一原因是因为客户端只有 IE6+。即便如此，它也存在问题。我发现 XSLT 非常困难，如果您打算这样做以获得调试和编辑 XSLT 的好工具，我会建议您这样做。为什么不使用 JSON 和 jquery？必须更标准，客户端可变性更少。

【讨论】：