XSLT Serverseitig vs XSLT Clientseitig

Mich würden mal eure Erfahrungen, falls vorhanden, zu diesem Thema interessieren.
Um das Thema etwas genauer zu erläutern.
Es gibt an sich 2 Möglichkeiten wie man XSLT nutzt. Serverseitig oder clientseitig.
In PHP kann ich z.B. mit dem XsltProcessor ein XML Dokument transformieren. Dies geschieht komplett serverseitig und an den Client wird dann nur das resultierende XHTML gesendet.
Ich kann aber dem Client auch ein XML Dokument mit einer Zeile wie die folgende senden:

Dann ist der Browser an der Reihe und muss das XML Dokument transformieren.
(korrigiert mich falls ich da falsch liege)
Ich habe bisher folgende Erfahrungen gemacht:
Wenn ich das ganze clientseitig transformieren lasse, sieht der Quellcode schöner aus (XML halt )... obwohl das rein subjektiv ist.
Ein Vorteil der serverseitigen Methode ist die hohe Rückwärtskompatibilität was die Browser betrifft. Obwohl die auch bei der clienseitigen Methode unerwartet Rückwärtskompatibel ist.
Was ich etwas nervig finde ist, dass bei der Clientseitigen Methode das ganze relativ pervers gecached wird. Ich habe es dadurch öfter, dass div Frames nicht dort sind wo sie sein sollten. Die sind dann oft noch an der Position, an der sie auf der vorherigen Seite waren.
Die Geschwindigkeit, rein subjektiv betrachtet kommt mir eigentlich gleich schnell vor!?
An sich funktionieren beide Methoden super, bloss bei der clientseitigen hatte ich am Anfang Probs, dass das auch im FF lief...
Erfahrungen, Hintergrundwissen, u.ä. erwüscht!

Ich würdes nur auf dem Client machen, wenn der Server schon aufm Zahnfleisch kriecht.
Außer der Lastverteilung hast du keine Vorteile es auf dem Client zu machen (außer dass es irgendwie schöner aussieht), und man sich natürlich auch besser fühlt, sich sowas ausgedacht zu haben . Du handelst dir aber die Inkompatibilitäten ein.

Ich kenn ein CMS (PHP), das komplett auf XSLT basiert (und zwar mit n-Modulen (jeweils XSLT) pro Seite (auch XSLT)). Die Geschwindigkeit wird auch bei großen Anwendungen nicht von den XSLTs bestimmt, da gibt es andere Faktoren (Datenbank), die einen wesentlich größeren Zeitfaktor besitzen. Natürlich wird da auch gecached, teilweise aber auch nur das XML.
Je nach Komplexität stößt eine lokale Variante an ihre Grenzen, wenn man mit Parametern etcpp. arbeiten will - und du kannst nicht sichern sein, dass der Betrachter einen vernünftigen Betrachter (Browser) hat. Leider werden idR nie Fehler geschmissen, d.h. selbst der Benutzer kann keine Fehler melden.
Für geschlossene Anwendungen (Intranet mit vorgegebenen Browser) finde ich solche Lösungen evtl. möglich, da sollte die Last aber eh nicht so hoch sein, dass man die geringe Transformation an die Clients weiterreicht.

Gibt es denn irgendwo eine Liste, welche Browser XSLT 2.0 und XPath 2.0 unterstützen? Wenn ja könnte man doch den Browser ermitteln, den der Benutzer gerade hat. Unterstützt dieser XSLT und XPath, wird die Transformation am Client gemacht bzw. wenn nicht, wird diese am Server gemacht.
Wär das keine Idee?
Ich finde nicht, dass man alles auf dem Serer machen sollte nur weil es Browser gibt, die es nicht unterstützen. Es gibt auch Browser, die können sich nicht an HTML Standards halten, soll man deswegen alle Seiten als PDF ausgeben?

Ich musste da grade an die XHTMLAsHTMLMiddleware (code.ibofobi.dk/public/wiki/XHTMLAsHTMLMiddleware) für Django denken. Denn diese Problematik ergibt sich nicht nur bei noch relativ wenig verbreiteten Techniken wie XSLT, sondern auch bei XHTML.
Ach und da gibt es noch einen Artikel warum man kein XHTML nutzen sollte. Wobei mich die Argumente jetzt nicht so umhauen: hixie.ch/advocacy/xhtml

PHP unterstützt schon mal kein XSLT 2.0
Einen Browser der XSLT 2.0 unterstützt kenne ich auch nicht. Da XSLT 2.0 erst ca. 1.2 Jahr alt ist (verabschiedet am 2. Jan 2007) wundert mich das überhaupt nicht.
Der einzige Processor der das Unterstützt den ich kenne ist der Saxon(java/.net).

Original von planetenkiller
PHP unterstützt schon mal kein XSLT 2.0

Und kein "xhtml" als Ausgabeformat anscheinend. Das rückt den Thread für mich in ein anderes Licht und macht das schöne XSLT schon wieder fast unbrauchbar...

Original von planetenkiller

Einen Browser der XSLT 2.0 unterstützt kenne ich auch nicht. Da XSLT 2.0 erst ca. 1.2 Jahr alt ist (verabschiedet am 2. Jan 2007) wundert mich das überhaupt nicht.
Mich wundert es schon, dass die Entwicklung der Browser so langsam voran geht, dass man kaum neuere Techniken benutzen kann.

Original von planetenkiller

Der einzige Processor der das Unterstützt den ich kenne ist der Saxon(java/.net).
AltovaXML beherrscht es glaube ich auch schon.
PS: Und wie sieht die Unterstützung von XSLT 1.0 in Verbindung von XPath 1.0 bei den Browsern aus? Firefox 2 und IE 7 scheinen damit schon mal kein Problem zu haben.

Naja habt ihr mal clientseitiges XSL in der Praxis erlebt? Blizzards WoW armory nutzt es... und es ist definitiv die Webseite, die mir mit Abstand am haeufigsten den Browser abgeschossen hat.

Ich kann auch mit Java oder JavaScirpt einen Browser durch Endlosschleifen oder ähnliches zum Absturz bringen, und? Wenn das XSL läuft, dann sehe ich darin kein Problem es im Browser des Anwenders zu überlassen.
Es stellt sich nur die Frage, was man mit den Browsern macht, die diese Funktionalität nicht haben. Ausschließen kommt für mich nicht in Frage, daher hätte ich die Browserinformation genutzt um für ältere Browser die Transformation beim Server zu machen.
Aber ja, ich lerne ja gerade XSLT und führe meine Beispiele einfach in den Browsern aus und überlasse denen die Arbeit. Es läuft flüssig und ich sehe darin kein Problem.

Original von Kallisti
Naja habt ihr mal clientseitiges XSL in der Praxis erlebt? Blizzards WoW armory nutzt es... und es ist definitiv die Webseite, die mir mit Abstand am haeufigsten den Browser abgeschossen hat.

Die ganze offizielle WOW Seite nutzt es. Hat bei mir bisher noch nicht einmal den Browser abgeschoßen

> mir mit Abstand am haeufigsten den Browser abgeschossen hat.
Yeah, Browserflamewar... Mit einem richtigen Browser wäre es nicht passiert.
Ich persönlich würde mich nicht auf clientseitiges XSLT verlassen. Ich würde alle fähigen Browser in eine Whitelist packen und diese erhalten das XSLT+Xml. Alle anderen Browser erhalten vom Server verarbeiteten XHtml-Code...

Original von DrakeL

Original von planetenkiller
PHP unterstützt schon mal kein XSLT 2.0

Und kein "xhtml" als Ausgabeformat anscheinend. Das rückt den Thread für mich in ein anderes Licht und macht das schöne XSLT schon wieder fast unbrauchbar...
Ich habe xml genommen:

utput method="xml" encoding="UTF-8" indent="yes" omit-xml-declaration="yes"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"/>
Funktioniert bestens.

Original von planetenkiller
Funktioniert bestens.

Nur schade, dass xhtml nicht 100% kompatible dazu ist. Man denke da an oder . Ich weiß zwar nicht, ob das durch die Methode xhtml abgedeckt werden würde, aber auf jeden Fall wäre das ansonsten ein Problem, das man beachten müsste.

Original von TheUndeadable

Ich persönlich würde mich nicht auf clientseitiges XSLT verlassen. Ich würde alle fähigen Browser in eine Whitelist packen und diese erhalten das XSLT+Xml. Alle anderen Browser erhalten vom Server verarbeiteten XHtml-Code...
Genau das hab ich ja gemeint. Würde ich auch gerne machen, aber woher die Information nehmen, welche Browser es unterstützen und welche nicht. Gibt es da eine Liste oder muss ich alle ausprobieren?

Die Frage ist ja wie man "unterstuetzen" definiert.
Firefox unterstuetzt es durchaus, aber armory.wow-europe.com/ hat mir im Laufe der Zeit eben zig mal den Browser (Firefox 2 und ja, auch den Internet Explorer @ Undeadable ausweichend hab ich den ebenfalls manchmal zur Hand genommen, wenn der Firefox schon gar nicht drauf klar kam) abgeschossen. Ab und an geht es sicher ein paar Tage gut und vielleicht haben sie es mittlerweile auch im Griff, aber von wirklich zufriedenstellender Stabilitaet kann man in dem Fall absolut nicht sprechen.

Original von Kallisti
Die Frage ist ja wie man "unterstuetzen" definiert.

Welche Browser XSLT 1.0 und XPath 1.0 unterstützen und verarbeiten können. Was ist an der Frage so schwer zu verstehen? Ich will nicht wissen...

Original von Kallisti

Firefox unterstuetzt es durchaus, aber armory.wow-europe.com/ hat mir im Laufe der Zeit eben zig mal den Browser (Firefox 2 und ja, auch den Internet Explorer @ Undeadable ausweichend hab ich den ebenfalls manchmal zur Hand genommen, wenn der Firefox schon gar nicht drauf klar kam) abgeschossen. Ab und an geht es sicher ein paar Tage gut und vielleicht haben sie es mittlerweile auch im Griff, aber von wirklich zufriedenstellender Stabilitaet kann man in dem Fall absolut nicht sprechen.
...welche Browser mit verkorkstem XSLT klar kommen. Ich rede ja von sauberem Funktionierenden XSLT, und das sollten alle Browser können die den Standard auch unterstützen. Alle andere werden mit vom Server verarbeitetem Ergebnis beliefert.

Original von planetenkiller
Ich habe xml genommen:

utput method="xml" encoding="UTF-8" indent="yes" omit-xml-declaration="yes"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"/>
Funktioniert bestens.

Oha ich saß letztens 3h um herauszufinden, dass eine website genau deswegen im FF nicht funktionierte (im IE gings ). Mit method="html" ging es dann auch im FF (handelt sich dabei bei um v2).

OK, wir sagen: Mit viel Aufwand kann man es hinbekommen.
Aber wozu?

Mir ist da gerade noch ein Gedanke gekommen. Denn wie sehen dann die Suchmaschinen Bots die Webseite, bei einer Clientseitigen transformation.
Ich kann mir fast nicht vorstellen, dass der Bot die Seite erst transformiert und dann durchschaut.
Da die Bots den Inhalt auch an Hand seiner Tags bewertet (z.B. h1,h2,h3 werden direkt als Überschrift mit der jeweiligen Gewichtung erkannt) hat man doch dann bei der clientseitigen transformation einen Nachteil, oder?

die crawser sollte man doch z.b. per robotst.txt auf eine statische seite linken können, oder?
wäre suboptimal, aber löst das problem.
Alternativ kann man (auf bgs bezogen) ja auch xlst nur ingame verwenden und das ganze außen 'drumherum' ohnehin statisch machen (oder generieren und statisch zwischenspeichern).

Oder den Bots einfach eine serverseitig transformierte Seite geben. Wäre halt nur möglich, wenn man diese von normalen Nutzern unterscheiden kann (?)

müsste man per http-header können .. weil der google-bot identifiziert sich auch als solcher, wenn man sich den browser-header anschaut.
Ich weiss grade nicht, wie der sich genau nennt.. müsste ich mal mein acces-log durchsuchen.
so schaut das bei mir aus:

66.249.66.130 mission-unknown.de - [16/Jun/2008:20:59:43 +0200] "GET /robots.txt HTTP/1.1" 404 345 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +www.google.com/bot.html)"

sprich den header einfach nach googlebot parsen ..
yahoo macht dasselbe:

74.6.18.253 mission-unknown.de - [17/Jun/2008:11:47:20 +0200] "GET / HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; help.yahoo.com/help/us/ysearch/slurp)"

am besten einfach mal das access-log parsen (lassen).. kannst ja mit analog nen bericht erstellen und einstellen, dass er dir jeden zugriff jedes browsers nach browsern sortiert anzeigen soll... dann weisst du, welche crawler da waren ..
alternativ kann man ja auch ne Sitemap erstellen

Stimmt denen ne fertige Version vorwerfen ist ne Lösung.
Drezil danke auch für die Detailierten Infos und gz zum 1000. Post

In der aktuellen c't findest du einen kurzen Bericht über XSLT.
Ist allerdings meiner Meinung nach nicht sonderlich gut.

Original von TheUndeadable
In der aktuellen c't findest du einen kurzen Bericht über XSLT.
Ist allerdings meiner Meinung nach nicht sonderlich gut.

"Dynamische Websites bauen mit XSLT" klingt iwie nach einem Tutorial und erinnert mich auch nich an ein Tutorial in meinem Blog
Wäre an sich nur interessant wenn die dort auf das Thema "XSLT Serverseitig vs XSLT Clientseitig" eingehen?

Original von n26
Wäre an sich nur interessant wenn die dort auf das Thema "XSLT Serverseitig vs XSLT Clientseitig" eingehen?

Die sagen clientseitig ist super weil:
a) es alle aktuellen Browser (Konqueror ausgenommen) unterstützen
b) es von der Rendergeschwindigkeit keinen spürbaren Unterschied zu HTML & Co. macht.
Natürlich bleibt das Problem mit älteren Browserversionen. Aber dafür ginge ja serverseitig. Ich fand eigentlich recht spannend was für Möglichkeiten die in dem Artikel aufgezeigt haben. Ging um so lustige Sachen wie verschachtelte Menüs oder Breadcrumps mit XSLT zu generieren.

Danke für die kurze Zusammenfassung. Werde ich mir eventuell mal anschauen! (auch wenn ich 15min dafür im Zeitungsladen rumstehe )

Original von n26
Danke für die kurze Zusammenfassung. Werde ich mir eventuell mal anschauen! (auch wenn ich 15min dafür im Zeitungsladen rumstehe )

Die drei Euro für eine ct wirst du ja wohl noch übrig haben. Alternativ könnt ich den Artikel auch einscannen wenn Bedarf besteht.

Danke fürs Einscan-Angebot, aber bei 3€ werde ich sie mir wohl mal leisten

Original von Dunedan
Ging um so lustige Sachen wie verschachtelte Menüs oder Breadcrumps mit XSLT zu generieren.

Was denn sonst noch?

Da ich gerade dabei bin, das ganze mal so umzusetzen, dass es untransformiert an den Client geschickt wird, bin ich direkt auf nen weiteren Nachteil der clientseitigen Transformation gestoßen.
Ich muss auf das praktische

XSLTProcessor::setParameter

verzichten, was die übergabe von dynamischen Variablen erheblich erschwert.

Falls es jemanden Interessiert. Es gibt noch einen erheblichen Nachteil von der Clientseitigen Variante. Denn kein aktueller Browser (und nat. auch kein älterer) hält sich an das omit-xml-declaration Attribut des xsl:output Tags.

Dadurch habe ich z.B. gerade Probleme, dass das entstehende XML Dokument auch als RSS Feed erkannt wird.

Das alles sind die Dinge, warum ich client-seitig für den "Mainstream" derzeit nicht so berauschend finde. Für ne Intranetlösung o.ä. ist das völlig akzeptabel... aber sowas geht nicht.

Das mit den Parametern ist ein gutes Argument - ist das auf Seite 1 hier echt nicht erwähnt worden? :)