任何使用Client Side XSLT的大型网站？

Question

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

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

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

我的问题是：有没有使用这种方法的大牌或大流量网站，如果是这样的话：你从中获取了哪些限制/经验教训？

感谢互联网， 扎克

Answer 1

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

在Firefox中，任何使用document.write的javascript都会破坏DOM。另外，firefox的noscript插件会阻止客户端xsl。在这两种情况下，用户都不会看到任何内容。似乎没有办法检测到这种错误，因此后退将无效。

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

这些是我想到的东西。这是一个很好的想法，但要注意这些问题。

Answer 2

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

Answer 3

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

然而，我不时会自己思考同样的问题，我假设互联网上的此类网站数量必须非常接近于零。 ： - ）

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

Answer 4

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

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

Answer 5

我目前正在运行一些带有客户端XSLT的小页面，所有这些都是瑞典语（lillemanfestivalen.se，resihop.nu和beta项目）。我最担心的是谷歌没有索引我的网页内容，只是没有转换的XML。但是，自从我一周前推出了resihop.nu以来，它出现在谷歌转换！ ：d

现在我的另一个问题是Facebook和其他社交网站，它们不了解如何处理它。然而，我仍然认为上行方面比下方大。我得到的绝佳速度和分离非常棒。使用resihop.nu，我甚至不开发单独的API，我只是将开发人员指向网站本身。 （虽然需要更多的工作才能使它变得更好）

Answer 6

我同意以利亚的回答。我认为使用客户端XSLT是一项艰巨的任务。你必须为它做很多质量保证。但是对于服务器端，你没有那个QA。在使用客户端时，您必须照顾所有类型的客户端和可能性。使用客户端XSLT时，您的代码可能会中断。

Answer 7

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