Ich beschäftige mich derzeit ein bisschen mit XSL, das ist die Transformierung von XML-Daten in andere XML-Daten, zB XHTML.
Ein praxisorientiertes Beispiel: Aus einem RSS-Feed als XML-Datenquelle kann man mit XSL (welches auch wieder "nur" XML ist) eine News-XHTML-Seite bauen.. das geniale ist: Setzt man das Clientseitige Processing ein (was allerdings nun ja.. man kennt das "Client-Problem" ja.. ), dann reicht ein Stylesheet im RSS/XML-Dokument.. alternativ kann man auch den Server das Processing erledigen lassen (u.a. PHP kann das, entsprechende Module natürlich voraussgesetzt) und erhält ein XHTML-Dokument, was auf jedem Client gleich aussieht (das XHTML-Dokument, nicht das visuelle Anzeigeergebnis).
Setzt man nun XSL im großen Stile ein, dann benötigt man ja eigentlich kein Templatesystem a la Smarty mehr.. denn die Ausgaben geschehen eh in einer reinen Datenstruktur.. man bräuchte halt nur eine entsprechende Eingabe-Ausgabelogik (zb Array2XML). Zusätzlich: Beim serverseitigem Processing können PHP-Funktionen eingebunden werden.
Vorteile: Man kann aus reinen XML-Daten (die sich bestmöglichst in der Struktur nicht mehr ändern) verschiedene Templates schaffen, je nach Anforderung. Man kann die gleiche XML-Datei/Quelle für Feed, für XHTML, für was wei´ß ich nicht nutzen.
Nachteile: Der Server muss immer ein Processing, d.h. also eine Transformierung der XML-Daten mit der Vorlage der XSL-Datei machen (bei Foren/Homepages geschieht das weniger oft, bei Browsergames öfters).
Im Idealfall würde clientseitiges processing reichen, dann ist der Traffic nur noch Daten, da die XSL dann einmal gecached vorhanden ist.. aber da jeder Browser seinen eigenen Mist macht..
Hat jemand Erfahrungen damit.. und wie verhalten sich die "konventionellen" Templatesystem dazu? Was sind eure Meinungen?
XSL Templatesystem.. Templatesystem?
gepostet vor 18 Jahre, 5 Monate von knalli
gepostet vor 18 Jahre, 5 Monate von Klaus
Ja XSL ist eine sehr komplizierte Sache.
Ich mache es sehr ähnlich, allerdings mit ganz anderen Mitteln. Mit meiner Fensterklasse (wenn sie mal läuft) wird beim Erstellen ein XHTML Template für die Div-Box per Request geladen, ausgegeben und für weitere Anfragen gecached. Dann werden die benötigten Daten angefordert und per JSON übertragen und schließlich per JS und DOM in das neue Template eingetragen.
Dank JSON muss man sich nicht mit dem DOM herumschlagen, was bei komplexen XML Daten doch sehr nervig sein kann. Das wäre auch der einzige Grund für mich XSL zu verwenden.
Ich mache es sehr ähnlich, allerdings mit ganz anderen Mitteln. Mit meiner Fensterklasse (wenn sie mal läuft) wird beim Erstellen ein XHTML Template für die Div-Box per Request geladen, ausgegeben und für weitere Anfragen gecached. Dann werden die benötigten Daten angefordert und per JSON übertragen und schließlich per JS und DOM in das neue Template eingetragen.
Dank JSON muss man sich nicht mit dem DOM herumschlagen, was bei komplexen XML Daten doch sehr nervig sein kann. Das wäre auch der einzige Grund für mich XSL zu verwenden.
gepostet vor 18 Jahre, 5 Monate von knalli
Dachte ich auch.. es geht eigentlich. Es gibt zwar wahnsinnig viele Möglichkeiten, wenn man sich mal so "beispiele" anschaut:; aber ein einfaches Template hat man schnell zusammengeschustert. Sofern man geschnallt hat, was DOM und XPath ist, ist einem die Struktur hier auch sofort in der Birne.. was will man mehr
bzgl. Fensterklasse: Ich habe den Fenstererstellalgorithmus derzeit einfach als Script (DOM) integriert, imho könnte man überlegen, sich ein JSON/XML-Array als "Notation" zu laden.. aber ein komplettes XHTML Template laden?
bzgl. Fensterklasse: Ich habe den Fenstererstellalgorithmus derzeit einfach als Script (DOM) integriert, imho könnte man überlegen, sich ein JSON/XML-Array als "Notation" zu laden.. aber ein komplettes XHTML Template laden?
gepostet vor 18 Jahre, 5 Monate von Klaus
Original von knalli
[...]aber ein komplettes XHTML Template laden?
Das sehe ich noch als einfachste Möglichkeit komplexe Strukturen darzustellen. Die Templates werden eh nur einmal pro Login geladen. Das kann man mit dem Browsercache natürlich noch herunterfahren, aber dann läuft man gefahr das die Daten dort veralten.
gepostet vor 18 Jahre, 5 Monate von knalli
Ich bin ein bisschen weiter.. werde demnächst mal ein paar Erfahrungsberichte bezgl Laufzeitproblemen und -lösungen posten/mitteilen.
gepostet vor 18 Jahre, 4 Monate von knalli
Also, prinzipiell ist es einfach.
Sofern man sich mit dem HTML-Standard (besser: XHTML, besser XHTML 1.*, besser XHTML 1.0 Strict / 1.1) auskennt und weiß, wie man prinzipiell ein XML anwendet und "beschreibt", der kann auch XSL. Man sollte zudem wissen, was XPath bedeutet und, was man aber auch während der Benutzung lernen kann, wie man die gängigsten Abfragen in XPath realisiert. Wer noch nicht weiß, das ein XML (auch XHTML) Dokument nichts anderes als ein Baum mit Eltern und Kindern ist, der sollte sich erstmal hier vertiefen.. für XSL unabdingbar.
Mein erstes Beispiel (falls sich jemand mal XSL anlernen will): Ich habe RSS und Atomfeeds per XSL in ein XHTML Dokument transformiert.
Da XSL auch per XML "geschrieben" wird, ist der produzierte XHTML-Sxntax mindestens wohlgeformt. Also, d.h. es ein gültiges XML (alle Tags richtig geschlossen, Anführungszeichen verwendet, terminierende Tags und so weiter).
Ob nun das XHTML Dokument auch valide ist (also: ob die Tagnamen und Attributwerte/namen vorhanden sind und ob die Reihenfolge von Tags (ineinander) so sein darf), ist natürlich durch ein XSL alleine nicht gegeben.
Aber.. durch eine umsichtige Anordnung der Elemente lässt sich mit einem relativ kurzen Template eine komplette Internetanwendung beschreiben.. einmal valid, immer valid!
In der besagten Internetanwendung (Projekt vom Freund, wir wollen beide unseren XML/XSL Horizont erweitern ) werden alle Ausgaben nun in XML gemacht; dazu haben wir einen eigenen "Standard" entwickelt, also eine gültige Struktur, die jede "Ausgabeseite" hat. Mithilfe meines Templates kann ich so jede Ausgabeseite transformieren. Mithilfe von Xpath und gängien Knotenfunktionen lassen sich auch automatische Zählungen durchführen; auch ein colspan-Attribut kann ich so mit Leichtigkeit in eine unbekannt dimensionierte Tabelle legen. Auch alternative Farben (Zeile1, Zeile2, Zeile1, ..) sind kein Problem. Ohne ein Stück Code.
Derzeit überlege ich, ob eine i18n-Lösung sich sinnvoll in ein XML-XSL Geflecht einbringen lässt; denn die Möglichkeiten wären sehr interessant.
Zum Thema Laufgeschwindigkeit:
Ich habe testweise verschiedene Varianten ausprobiert: Mit einem Dokument mit vielen Einträgen (also viele XHTML Knoten) habe ich gemacht:
* ein normales PHP-Template, d.h. include(php), welche nur aus html, php-echo und php-if, php-for etc besteht.. quasi ähnlich Smarty
* ein Smarty-Template
* ein XML generierter Baum per DomDocument von Php, der anschließend mit dem XSLProcessor in XHTML umgewandelt wird.
Es hat sich wie erwartet gezeigt (ich sage mal Größen, die sich auch bei Wiederholungen nicht qualitativ groß geändert haben):
* PHP-Template: 1.2
* Smarty-Template: 1.8
* XML/XSL: 4.1
Da ich APD nutzte, um die effektiven Zeiten zu ermitteln (das microtime-Getüm war mir da zu unsicher, weil ich ja den gesammten Prozess messen wollte und.. folgendes), konnte ich auch sehen, was so viel Zeit benötigt hatte.
Im dritten Fall beanspruchte das Aufbauen des XMLs zuviel Zeit, die benötigte Zeit des appendChild aka new Object XY war immens. Also habe ich eine Alternative Methode geschrieben, die ein XML per konnektierten Strings erstellt. Sicherlich, die feine Art ist das eigentlich nicht, allerdings scheint es derzeit sonst wirklich keine bessere Möglichkeit zu geben. Diesen XML-String kann man dann mit dem DOMDocumentor importieren und anschließend als Objekt dem XSLProcessor übergeben.
Laufzeit? 1.4, soweit ich mich recht erinnere.. wichtig war nur: über PHP-Template (klar, das ist keine Überraschung) und unter Smarty (eigentlich auch keine Überraschung).
Smarty kann durch Vorkompilierung seitens Erweiterungen wie den Accelerator natürlich noch beschleunigt werden; prinzipiell könnte man den XSLProcessor in einer Anwendung aber ebenfalls modualisieren und somit bestimmte Teilbäume des Dokuments (zB Navigation, falls nicht in irgendeiner Form personalisiert oder durch Rechten modifizierbar) als "kompiliert" speichern.
Ich finds auf jeden Fall eine feine Sache.. und wäre nicht die Tatsache, dass die Browser so einen Murks mit XSL machen, könnte man sogar Clientside SXLProcessing machen.. womit alles (Performance) dafür sprechen würde.
Firefox 1.5 und 1.x zeigen wie der IE6 und IE7 die meisten Sachen scheinbar korrekt an.. Opera 8.5 schweigt sich komplett darüber aus (kann 0% XSL, und das ist ein W3C-Standard).. und die Browser in der Macwelt können es auch alle (oder sollte ich sagen: natürlich ).
Sofern man sich mit dem HTML-Standard (besser: XHTML, besser XHTML 1.*, besser XHTML 1.0 Strict / 1.1) auskennt und weiß, wie man prinzipiell ein XML anwendet und "beschreibt", der kann auch XSL. Man sollte zudem wissen, was XPath bedeutet und, was man aber auch während der Benutzung lernen kann, wie man die gängigsten Abfragen in XPath realisiert. Wer noch nicht weiß, das ein XML (auch XHTML) Dokument nichts anderes als ein Baum mit Eltern und Kindern ist, der sollte sich erstmal hier vertiefen.. für XSL unabdingbar.
Mein erstes Beispiel (falls sich jemand mal XSL anlernen will): Ich habe RSS und Atomfeeds per XSL in ein XHTML Dokument transformiert.
Da XSL auch per XML "geschrieben" wird, ist der produzierte XHTML-Sxntax mindestens wohlgeformt. Also, d.h. es ein gültiges XML (alle Tags richtig geschlossen, Anführungszeichen verwendet, terminierende Tags und so weiter).
Ob nun das XHTML Dokument auch valide ist (also: ob die Tagnamen und Attributwerte/namen vorhanden sind und ob die Reihenfolge von Tags (ineinander) so sein darf), ist natürlich durch ein XSL alleine nicht gegeben.
Aber.. durch eine umsichtige Anordnung der Elemente lässt sich mit einem relativ kurzen Template eine komplette Internetanwendung beschreiben.. einmal valid, immer valid!
In der besagten Internetanwendung (Projekt vom Freund, wir wollen beide unseren XML/XSL Horizont erweitern ) werden alle Ausgaben nun in XML gemacht; dazu haben wir einen eigenen "Standard" entwickelt, also eine gültige Struktur, die jede "Ausgabeseite" hat. Mithilfe meines Templates kann ich so jede Ausgabeseite transformieren. Mithilfe von Xpath und gängien Knotenfunktionen lassen sich auch automatische Zählungen durchführen; auch ein colspan-Attribut kann ich so mit Leichtigkeit in eine unbekannt dimensionierte Tabelle legen. Auch alternative Farben (Zeile1, Zeile2, Zeile1, ..) sind kein Problem. Ohne ein Stück Code.
Derzeit überlege ich, ob eine i18n-Lösung sich sinnvoll in ein XML-XSL Geflecht einbringen lässt; denn die Möglichkeiten wären sehr interessant.
Zum Thema Laufgeschwindigkeit:
Ich habe testweise verschiedene Varianten ausprobiert: Mit einem Dokument mit vielen Einträgen (also viele XHTML Knoten) habe ich gemacht:
* ein normales PHP-Template, d.h. include(php), welche nur aus html, php-echo und php-if, php-for etc besteht.. quasi ähnlich Smarty
* ein Smarty-Template
* ein XML generierter Baum per DomDocument von Php, der anschließend mit dem XSLProcessor in XHTML umgewandelt wird.
Es hat sich wie erwartet gezeigt (ich sage mal Größen, die sich auch bei Wiederholungen nicht qualitativ groß geändert haben):
* PHP-Template: 1.2
* Smarty-Template: 1.8
* XML/XSL: 4.1
Da ich APD nutzte, um die effektiven Zeiten zu ermitteln (das microtime-Getüm war mir da zu unsicher, weil ich ja den gesammten Prozess messen wollte und.. folgendes), konnte ich auch sehen, was so viel Zeit benötigt hatte.
Im dritten Fall beanspruchte das Aufbauen des XMLs zuviel Zeit, die benötigte Zeit des appendChild aka new Object XY war immens. Also habe ich eine Alternative Methode geschrieben, die ein XML per konnektierten Strings erstellt. Sicherlich, die feine Art ist das eigentlich nicht, allerdings scheint es derzeit sonst wirklich keine bessere Möglichkeit zu geben. Diesen XML-String kann man dann mit dem DOMDocumentor importieren und anschließend als Objekt dem XSLProcessor übergeben.
Laufzeit? 1.4, soweit ich mich recht erinnere.. wichtig war nur: über PHP-Template (klar, das ist keine Überraschung) und unter Smarty (eigentlich auch keine Überraschung).
Smarty kann durch Vorkompilierung seitens Erweiterungen wie den Accelerator natürlich noch beschleunigt werden; prinzipiell könnte man den XSLProcessor in einer Anwendung aber ebenfalls modualisieren und somit bestimmte Teilbäume des Dokuments (zB Navigation, falls nicht in irgendeiner Form personalisiert oder durch Rechten modifizierbar) als "kompiliert" speichern.
Ich finds auf jeden Fall eine feine Sache.. und wäre nicht die Tatsache, dass die Browser so einen Murks mit XSL machen, könnte man sogar Clientside SXLProcessing machen.. womit alles (Performance) dafür sprechen würde.
Firefox 1.5 und 1.x zeigen wie der IE6 und IE7 die meisten Sachen scheinbar korrekt an.. Opera 8.5 schweigt sich komplett darüber aus (kann 0% XSL, und das ist ein W3C-Standard).. und die Browser in der Macwelt können es auch alle (oder sollte ich sagen: natürlich ).