2008-11-08 3 views
22

In letzter Zeit habe ich über die etwas nicht-Mainstream-Architektur der Erstellung von Roh-XML auf der Serverseite nachgedacht und dann ein XSLT-Stylesheet auf dem Client verwendet, um das XML in die vollständige Benutzeroberfläche umzuwandeln. Natürlich müsste ein Fallback-Mechanismus existieren, wenn der Client nicht in der Lage wäre, clientseitig XSLT zu verwenden. In diesem Fall würden wir ihn einfach serverseitig für ihn transformieren.Große Websites, die Client-Side-XSLT verwenden?

Ich bin bereits vertraut mit XSLT, und dieser Ansatz scheint eine saubere Trennung von Präsentation und Inhalt zu sein, die Daten vollständig in XML zu zwingen und XSLT für die Präsentation zu verwenden.

Ich bin mir auch bewusst, dass dies eine zusätzliche Schicht der Komplexität der Anwendung hinzufügen, die nur ein anderes bewegliches Teil ist, das fehlschlagen kann.

Meine Frage ist: Gibt es einen großen Namen oder große Traffic-Sites mit diesem Ansatz, und wenn ja: Welche Einschränkungen/Lektionen gelernt hast du davon weggenommen?

Dank Internet, Zach

+0

Zwei Jahre später - benutzen Sie immer noch diese Technik? – Casey

+0

Nein, bin ich nicht. Mit einer Reihe von neuen (mobilen) Geräten kommt dies nicht Mainstream genug, um zu garantieren, dass es funktioniert. Sieht nicht so aus, als ob WoW das immer noch benutzt. – zachleat

+1

Sie haben es möglicherweise gerade von der Clientseite zur Serverseite verschoben. –

Antwort

13

Wie andere Leute erwähnt haben, hat Blizzard viele Seiten, die Client-Seite xsl sind. Ich würde empfehlen, Clientseite xsl zu vermeiden. Es ist eine wirklich coole Idee, aber es gibt viele ungewöhnliche Fehler, mit denen man umgehen muss.

In Firefox wird jedes Javascript, das document.write verwendet, das DOM zerstören. Das Noscript-Plug-In für Firefox stoppt auch die Clientseite xsl. In beiden Fällen wird der Benutzer nichts sehen. Es scheint keine Möglichkeit zu geben, diese Art von Fehlern zu erkennen, so dass ein Fallback nicht funktioniert.

In IE, wenn Sie etwas haben, das eine 30x-Umleitung zu etwas von einem anderen Ursprung (gehen von http zu https oder Überfahrt Sub-Domänen), erhalten Sie einen Fehler für die same origin policy verletzen. Du hast nicht wirklich die gleiche Herkunftsrichtlinie verletzt, aber IE verhält sich wie du. Wenn Sie beispielsweise zu http://foo.example.com/login wechseln und 302 eine Umleitung zu https://bar.example.com/login.xml durchführen, behandelt IE das xsl so, als ob es von bar.example.com käme, und behandelt das XML so, als käme es von foo.example.com. Sie müssen also zu einer Meta-Aktualisierung für Ihre Weiterleitungen zurückkehren.

Dies sind die Dinge, die ich von oben nach unten dachte. Es ist eine nette Idee, aber seien Sie sich dieser Probleme bewusst.

+0

interessant, hatte keine Ahnung von diesem. Dies sind jedoch seltene Fälle. Ich glaube, dass Client-seitiges XSLT die Zukunft ist. Die Vorlage an den Browser zu übergeben und sie mit Daten zu füllen ist wie das Internet funktionieren soll. Ich liebe, dass Blizzard es auf den meisten ihrer Seiten verwendet :). Aber wie alles clientside ... gibt es Browser-Kompatibilitätsprobleme (css, js ...) –

+0

+1 für den IE-Tipp. – harpo

+0

Wissen Sie, ob diese Fehler in IE9 und FF4 bestehen? – Casey

6

könnte ich Ihnen nicht im Detail sagen, wie es implementiert, aber World of Warcraft ist ziemlich groß und stark frequentiert und ihre Website implementiert ist, wie Sie beschreiben.

+1

Sie können die Implementierung Details für sich selbst sehen: http://www.worldofwarcraft.com/new-hp/layout/layout.xsl – nickf

+0

Versuchen Sie, auf die Seite in Safari gehen, dann sehen Sie sich die Quelle. Es verwendet nicht den obersten Knoten , sondern hat . Der Stylesheet-Prolog ist immer noch da, zeigt Safari die Ausgabe der Transformation an? – zachleat

+0

@zachleat: Die WoW-Site verwendet UA-Switching, um zu bestimmen, ob XML mit Stylesheet-Anweisungen oder vortransformiertem HTML geliefert werden soll. IIRC, nur IE6 + und FF2 + werden mit XML versorgt. –

3

Ich kenne keine großen öffentlichen Websites, die clientseitige XSLT-Transformation verwenden (na ja, außer World of Warcraft von Joel erwähnt :-). Daher kann ich deine Frage nicht direkt beantworten.

Aber von Zeit zu Zeit dachte ich selbst über die gleiche Frage nach, und ich habe die Hypothese, dass die Zahl solcher Seiten im Internet sehr nahe bei Null liegen muss. :-)

Die kurze Version meiner Theorie hinter dieser Hypothese lautet: Abgesehen von einigen ziemlich exotischen Fällen ist die Bereitstellung der Client-seitigen XSLT-Option einfach nicht die Mühe wert. :-)

2

Die Firma, an der ich im Jahr 2001 gearbeitet habe, hat ein Serverprodukt veröffentlicht, das genau die Architektur implementiert, die Sie beschreiben. Wir hatten sehr guten Erfolg, die Verarbeitung auf die Clients zu verlagern. Darüber hinaus konnten wir mithilfe der Client-Erkennung mithilfe des HTTP-Benutzeragenten die serverseitige XSL-Verarbeitung für sehr spezielle Clients wie japanische Mobiltelefone verwenden. Ich denke, dass die Websites/Dienste/Produkte, die diese Technik verwenden, dies ziemlich transparent für die Kunden tun. Allerdings glaube ich, dass der Trend in letzter Zeit darin besteht, die Server-Seite zu bearbeiten, so dass Sie nicht auf die speziellen Implementierungen von XSL für eine Vielzahl von Clients angewiesen sind, und Sie Unterstützung für einige XSL-Erweiterungen erhalten, die Sie nicht können zu verwenden, wenn die meisten Browser unterstützt werden.

Ich weiß, dass ich nicht direkt Ihre Frage nach der Benennung einiger bekannter Websites beantworte, aber ich hoffe, ich biete etwas Wertvolles für das Problem an. Also, im Grunde mein Punkt ist, dass, wenn die Performance-Einsparung Ihrer Template-Verarbeitung ist wertvoller als QA, Unterstützung und Entwicklung für drei oder vier Browser ohne Erweiterungen, dann sollten Sie mit serverseitigen Verarbeitung bleiben.

0

Ich stimme Elijahs Antwort zu. Ich denke, dass die Verwendung von XSLT auf Clientseite eine schwierige Aufgabe ist. Sie müssen eine Menge QA dafür tun. Aber mit der Serverseite tun Sie diese QA nicht. Sie müssen sich um alle Arten von Clients und Möglichkeiten kümmern, während Sie die Client-Seite nutzen. Möglicherweise besteht die Möglichkeit, dass Ihr Code während der Verwendung von XSLT auf der Clientseite beschädigt wird.

0

Ich mag voreingenommen sein, wenn ich das sage, aber an einer Web-basierten App, die das tut, hasse ich es. Der einzige Grund, warum es überhaupt möglich ist, ist, weil die Clients nur IE6 + sind. Selbst dann gibt es Probleme damit. Ich finde XSLT sehr schwierig und würde vorschlagen, wenn Sie dies tun, um ein gutes Werkzeug zum Debuggen und Bearbeiten von XSLT zu bekommen.Warum nicht JSON und jquery verwenden? Muss mehr Standard und weniger Client-seitige Variabilität.

2

Ich führe gerade ein paar kleinere Seiten mit Client-Seite XSLT, alle auf Schwedisch (lillemanfestivalen.se, resihop.nu und Beta-Projekte). Meine größte Sorge war, dass Google meine Seiteninhalte nicht indexierte, nur das XML ohne die Transformation. Jedoch, da ich resihop.nu vor einer Woche gestartet habe, zeigt es sich auf Google mit Transformation! : D

Jetzt ist meine andere Sorge Facebook und andere soziale Seiten, die nicht verstehen, wie man damit umgeht. Ich denke immer noch, dass die oberen Seiten größer sind als die unteren Seiten. Die fabelhafte Geschwindigkeit und Trennung, die ich bekomme, ist fantastisch. Und mit resihop.nu entwickle ich nicht einmal eine separate API, ich zeige Entwickler nur auf die Seite selbst. (Mehr Arbeit wird dort gebraucht, um es gut zu machen)

+0

Ich habe jetzt ein paar mehr, kleine größere Websites mit Client-Seite XSLT gestartet. Und es scheint, dass Google tatsächlich hart darauf anschlägt, wenn sie es finden. :( – Lilleman

Verwandte Themen