XSLT als Template-Engine
gepostet vor 18 Jahre, 2 Monate von None
In welcher Hinsicht verwendet ihr (die es halt verwenden) XSLT als Template-Eingine? Funktionsweise und so.
gepostet vor 18 Jahre, 2 Monate von Tetha
(Das folgende ist der momentane Planungsstand)
Mein Ziel ist es, dem faehigen User zu ermoeglichen, ein komplett eigenes Interface zu schaffen, ohne ihn dabei zu nahe an meinen Code zu lassen.
Darum benutze ich halt XML/XSLT.
Ich habe als erstes ein Script, welches mindestens einen Parameter per Url uebergeben kriegt.
[list=1]
[*]ein gewisser Code, mit dem angezeigt wird, welche Daten geholt werden sollen (Beispielsweise die Accountdaten des aktuellen Users, aktuelle, oeffentliche Daten eines anderen Users , informationen ueber ein Land usw)
[*]ein Name einer XSLT-Datei
[*]eventuelle Zusatzparameter, beispielsweise die Kennung eines Users, eines Landes, ein geaenderter Parameter oder Aehnliches
[/list=1]
Das Script untersucht dann zunaechst, ob die Parameter valide sind.
Wenn sie dann valide sind, werden die entsprechenden Daten aus der Datenbank geholt und in passendes XML umgewandelt.
Wenn dann der User angegeben hat, dass er keine lokalen Interfacedaten nutzen will, so wird das XML direkt mit einem auf dem Server liegenden Anwendungsscript durch ein - ebenfalls auf dem Server liegendes - Template gejagt und das entstehende HTML dann an den User geschickt.
Hat der User dagegen angegeben, dass er lokale Interfaces verwenden will, so wird ein entsprechender Assoziationstag mit dem uebergebenen Dateinamen in das XML eingefuegt und dann das XML an den Browser geschickt.
Das ist die Variante, die ich bisher am Ueberzeugenzsten fand, da sie zum einen moeglichst minimale Anforderungen an einen Browser stellt (vor allem auch dann, wenn man beim Login die Moeglichkeit gibt, die aktuellen Templateeinstellungen zu ueberladen), zum anderen aber maximale Designmoeglichkeiten an den User gibt, ohne dabei grosse Sicherheitsprobleme auf sich zu laden.
MfG
Mein Ziel ist es, dem faehigen User zu ermoeglichen, ein komplett eigenes Interface zu schaffen, ohne ihn dabei zu nahe an meinen Code zu lassen.
Darum benutze ich halt XML/XSLT.
Ich habe als erstes ein Script, welches mindestens einen Parameter per Url uebergeben kriegt.
[list=1]
[*]ein gewisser Code, mit dem angezeigt wird, welche Daten geholt werden sollen (Beispielsweise die Accountdaten des aktuellen Users, aktuelle, oeffentliche Daten eines anderen Users , informationen ueber ein Land usw)
[*]ein Name einer XSLT-Datei
[*]eventuelle Zusatzparameter, beispielsweise die Kennung eines Users, eines Landes, ein geaenderter Parameter oder Aehnliches
[/list=1]
Das Script untersucht dann zunaechst, ob die Parameter valide sind.
Wenn sie dann valide sind, werden die entsprechenden Daten aus der Datenbank geholt und in passendes XML umgewandelt.
Wenn dann der User angegeben hat, dass er keine lokalen Interfacedaten nutzen will, so wird das XML direkt mit einem auf dem Server liegenden Anwendungsscript durch ein - ebenfalls auf dem Server liegendes - Template gejagt und das entstehende HTML dann an den User geschickt.
Hat der User dagegen angegeben, dass er lokale Interfaces verwenden will, so wird ein entsprechender Assoziationstag mit dem uebergebenen Dateinamen in das XML eingefuegt und dann das XML an den Browser geschickt.
Das ist die Variante, die ich bisher am Ueberzeugenzsten fand, da sie zum einen moeglichst minimale Anforderungen an einen Browser stellt (vor allem auch dann, wenn man beim Login die Moeglichkeit gibt, die aktuellen Templateeinstellungen zu ueberladen), zum anderen aber maximale Designmoeglichkeiten an den User gibt, ohne dabei grosse Sicherheitsprobleme auf sich zu laden.
MfG
gepostet vor 18 Jahre, 2 Monate von knalli
Original von TheHawk
In welcher Hinsicht verwendet ihr (die es halt verwenden) XSLT als Template-Eingine? Funktionsweise und so.
Im Rahmen eines kompletten Recodes verwende ich es als Quasi-Ersatz einer Templateengine. Ein internes XML wird aufbereitet und kann optional ausgegeben werden. Derzeit gibt es ein Standard-XSL, theoretisch kann man aber auch mehrere verwenden. Beispielsweise, um später Userspezifische Templates (nicht nur CSS-Designs) anzubieten, oder ein "normales" Redesign, oder ein temporärer kompletter Restyle, zB zu Weihnachtem, Halloween o.ä.
Ich habe zudem Auswertungen (Statistiken, Rang) als XML abgespeichert; damit diese "unser" XSL verarbeiten kann, muss ich die erst umtransfomieren, da die semantische Struktur der öffentlichen Daten natürlich nicht mit der Dokumentstruktur übereinstimmt. Dort kommt da auch ein weiteres XSL zur Ausführung.
gepostet vor 18 Jahre, 2 Monate von Moogly
Ich habe beschäftige mich zurzeit mit XML und XSL. Ein großer Vorteil von XSL ist in Meinung Augen auch, dass man Elemente mit dem gleichen Tag nach bestimmten Parametern sortieren kann, d.h. du schreibst nur einmal solch ein XSL Template und schwupps kannst du alle möglichen Tabellen sortierbar machen!
Zurzeit überlege ich z.B. Savant3 dafür einzusetzen um XML vom Code zu trennen für eine schönere Übersicht. Was haltet ihr davon? Doppelt gemoppelt?!
Eine weitere Frage ist: Jagd ihr euer XML durch irgendwelche PHP-XSL-Parser? Ist doch eigentlich nicht nötig, oder? Die modernen Browser verstehen doch XML? Reicht es nicht, hier einfach ein XSL als Stylesheet einzubinden?
Gruß
Moo
Zurzeit überlege ich z.B. Savant3 dafür einzusetzen um XML vom Code zu trennen für eine schönere Übersicht. Was haltet ihr davon? Doppelt gemoppelt?!
Eine weitere Frage ist: Jagd ihr euer XML durch irgendwelche PHP-XSL-Parser? Ist doch eigentlich nicht nötig, oder? Die modernen Browser verstehen doch XML? Reicht es nicht, hier einfach ein XSL als Stylesheet einzubinden?
Gruß
Moo
gepostet vor 18 Jahre, 2 Monate von knalli
Nein, eben nicht alle Browser unterstützen XSL - oder nicht vollständig.
Beispiele? Erst ab IE6 gibt es XSLT (soweit ich richtig informiert bin); reicht für die meisten Dinge vllig aus. Opera unterstützt erst ab v9 (!) XSL, vorher sieht man dort nix/weiße unformatierte Seite. Und alle etwas älteren Versionen von Browsern haben hin und wieder eine Macke.
Derzeit würde ich serverside empfehlen; da es in PHP integriert ist, ist die Laufzeit angemessen, solang man nicht anfängt (das Problem hätte man aber so oder so *g*) und mittels oop dom die Knoten erstellt.
Was man aber jetzt sicher weiß: Man kann jederzeit von serverside auf clientside wechseln; oder Usern die Freiheit geben, ob sie es selber rendern wollen.
Beispiele? Erst ab IE6 gibt es XSLT (soweit ich richtig informiert bin); reicht für die meisten Dinge vllig aus. Opera unterstützt erst ab v9 (!) XSL, vorher sieht man dort nix/weiße unformatierte Seite. Und alle etwas älteren Versionen von Browsern haben hin und wieder eine Macke.
Derzeit würde ich serverside empfehlen; da es in PHP integriert ist, ist die Laufzeit angemessen, solang man nicht anfängt (das Problem hätte man aber so oder so *g*) und mittels oop dom die Knoten erstellt.
Was man aber jetzt sicher weiß: Man kann jederzeit von serverside auf clientside wechseln; oder Usern die Freiheit geben, ob sie es selber rendern wollen.
gepostet vor 18 Jahre, 2 Monate von None
Ich werde bei mir die Option anbieten, die XSL-Transormation entweder mit PHP durchzuführen (für ältere Browser), oder eben dem User die XML-Daten an den Browser zu schicken, das ein aufweist. Zweiteres ist für den Benutzer schneller, da die XSLT auf den Browser ausgelagert wird.
Andere Frage. Verwendet ihr für jedes Design 1 (alle template-rules in einer) oder mehere (modular aufgebaut) XSL-Dateien oder für jede Seite ein eigenes?
Andere Frage. Verwendet ihr für jedes Design 1 (alle template-rules in einer) oder mehere (modular aufgebaut) XSL-Dateien oder für jede Seite ein eigenes?
gepostet vor 18 Jahre, 2 Monate von knalli
Hm.. ich habe derzeit noch alles in einem.. ich hab schon überlegt, das eventuell späer zu teilen; zum Beispiel Layout, Werbung und die Tags, die ich "durchschleife".
Das Template ist derzeit 40kb groß, das meiste wird eh gebraucht, insofern hätte ich von einem modulbasierten im Moment nicht viel. ich entscheide das aber später; ist in der Entwicklungsphase erstmal zweitrangig und ist überdies - für mich - in einer Datei übersichtlicher. Natürlich, ohne eine vernünftige Outline der XML-Struktur würde ich mich dusselig suchen..
Die Frage ist eben, was du alles hast; ein riesige Logik für ein Element (zb eine große Tabelle, was auch immer) die nur auf 1/50 deiner Seiten gebraucht wird, die würde ich dann auch auf jeden auslagern.. es kommt auf die Relation an. Wenn man nur intern Templates entwickelt, kann es evtl effizienter sein, immer nur eine Datei einzuladen - da muss ich aber gestehen, das habe ich noch nicht ausgetestet (Geschwindigkeit).
Allgemein würde *ich* so vorgehen: Je Applikation, je Template (inkl verschiedene Designs/Styles) ein XSL-Set. Wenn dort dann Gemeinsamkeiten auftreten (vorher klären), die auseinanderfriemeln..
Das Template ist derzeit 40kb groß, das meiste wird eh gebraucht, insofern hätte ich von einem modulbasierten im Moment nicht viel. ich entscheide das aber später; ist in der Entwicklungsphase erstmal zweitrangig und ist überdies - für mich - in einer Datei übersichtlicher. Natürlich, ohne eine vernünftige Outline der XML-Struktur würde ich mich dusselig suchen..
Die Frage ist eben, was du alles hast; ein riesige Logik für ein Element (zb eine große Tabelle, was auch immer) die nur auf 1/50 deiner Seiten gebraucht wird, die würde ich dann auch auf jeden auslagern.. es kommt auf die Relation an. Wenn man nur intern Templates entwickelt, kann es evtl effizienter sein, immer nur eine Datei einzuladen - da muss ich aber gestehen, das habe ich noch nicht ausgetestet (Geschwindigkeit).
Allgemein würde *ich* so vorgehen: Je Applikation, je Template (inkl verschiedene Designs/Styles) ein XSL-Set. Wenn dort dann Gemeinsamkeiten auftreten (vorher klären), die auseinanderfriemeln..
gepostet vor 18 Jahre, 2 Monate von None
Original von knalli
Allgemein würde *ich* so vorgehen: Je Applikation, je Template (inkl verschiedene Designs/Styles) ein XSL-Set. Wenn dort dann Gemeinsamkeiten auftreten (vorher klären), die auseinanderfriemeln..
Kannst du das genauer erklären?
gepostet vor 18 Jahre, 2 Monate von knalli
Ich habe mich noch nicht aktiv mit dem Include beschäftigt..
Ich weiß ja nicht, inwieweit du dir das modulhafte vorgestellt hattest? Das ergibt sich in einem ordentlichen System eh von alleine; und jedes in eine eigene Datei zu verpacken ist meine Begriffe unnötig.
Angenommen, du hast eine Aufteilung wie folgt: Hauptelemente, Werbebanner, Besondere Tabellen und Sonstiges.
Dann könntest du default_main.xsl, default_adverts.xsl, default_tables.xsl, default_misc.xsl, und dann theme2_main.xsl... anvisieren.
Nur wie gesagt; ob sich das später überhaupt lohnt, muss man später gucken. Wenn man eh immer alles braucht, kann es auch in eins rein.
Ich weiß ja nicht, inwieweit du dir das modulhafte vorgestellt hattest? Das ergibt sich in einem ordentlichen System eh von alleine; und jedes in eine eigene Datei zu verpacken ist meine Begriffe unnötig.
Angenommen, du hast eine Aufteilung wie folgt: Hauptelemente, Werbebanner, Besondere Tabellen und Sonstiges.
Dann könntest du default_main.xsl, default_adverts.xsl, default_tables.xsl, default_misc.xsl, und dann theme2_main.xsl... anvisieren.
Nur wie gesagt; ob sich das später überhaupt lohnt, muss man später gucken. Wenn man eh immer alles braucht, kann es auch in eins rein.
gepostet vor 18 Jahre, 2 Monate von None
Wenn alles in einer Datei ist (bis auf spezifische Tabellen), und von jedem Script das selbe XSL benutzt wird, geht da nicht die Performance flöten, wenn eine große Anzahl User auf die selbe Datei zugreift?
gepostet vor 18 Jahre, 2 Monate von TheUndeadable
Die Datei wird bei häufigem Zugriff vom Betriebssystem gecacht und liegt vollständig im Speicher.
gepostet vor 18 Jahre, 2 Monate von exe
Ich würde schlicht aus Gründen der Übersicht die Templates in mehrere Dateien aufspalten. Wenn du mal 20 verschiedene Seiten in einem 5000 Zeilen großen Template liegen hast wirds langsam unübersichtlich.
Wenn es unbedingt benötigt wird kann man die Dateien dann nach dem Entwickeln wieder zu einem Template zusammenfügen. Mit ein paar Buildscripts sind solche Aufgaben dann auch wieder unkompliziert erledigt ..
Wenn es unbedingt benötigt wird kann man die Dateien dann nach dem Entwickeln wieder zu einem Template zusammenfügen. Mit ein paar Buildscripts sind solche Aufgaben dann auch wieder unkompliziert erledigt ..