[Templatesystem] Erfahrungen / Vorteile von XSLT/XML ggü. standard Templateengines

[ABC]

Hab mal überlegt das Templatesystem wegzulassen und dafür mit XML+XSLT zu arbeiten, aber es dann doch gelassen, da es 1. viel mehr Aufwand (beim Schreiben), 2. höchstwahrscheinlich auch mehr Rechenleistung braucht (man sollte das ganze auf Serverseite umwandeln, um eben Kompatibilitätsprobleme zu vermeiden) und 3. das Problem besteht, dass auch das XSLT-Dokument valides XML sein muss (hatte damals eine ziemlich verzwickte Situation mit einer Tabelle, bei der ich dann XHTML- und XSLT-Tags verschachteln musste und das brachte immer einen Parse-Error).
Bin dann doch lieber beim normalen Template-System geblieben

Das größte Problem hast du ja eigentlich bei diesen komplexen Templatesystemen. Nichts gegen Smarty und co. Sie sind sehr Leistungsfähig und einfach zu bedienen. Allerdings, sind das echte Parser Verbraucher. Denn ein TPL System sollte eigentlich nur das tun, was es tun sollte. Das sind Markierungen in Varibalenwerte ersetzen. Nicht mehr und nicht weniger. Alles andere erfordert das mehrfache Parsen, und das vervielfacht sich schneller man sich umsehen kann. Jedes Zusatzfuter muss so von TPL zu TPL geprüft und geparst werden.

Mein Vorschlag, und das beste was du machen kannst, bau dir ein eigenes, welches genau deinen Bedarf sätigt. So hast du optimal Leistung und Bedarf gestillt.

Die Leistungsschwachen Verbraucher TPL Systeme sind jenige die mit implode() abrbeiten. Sie greifen nur gering auf Parserleistung zurück.

Grüsse Lukasz!

 

[Johnson]

Das sind Markierungen in Varibalenwerte ersetzen. Nicht mehr und nicht weniger.

Und wenn ich z.B. ein Array in Zeilen ausgeben will ? Dann sind Schleifen in Templates sehr nützlich.

Du weist aber, dass genau dies eine Sicherheitslücke extremen Grades schafft. Nicht alles "ach so toll mach ich gut" ist rentabel. Und auch nur wenige schützen ihren Template Ordner mit einer thaccess Datei.

Wenn du mich fragst warum? Ist ganz einfach. Wo ein template ist, dort ist die Variable versteckt, welche vom Script verarbeitet wird. Wer diese kennt, kann versuchen mit diesen zu spielen.

Der Auslieferung eines Templates sowohl mit VALUE Werten, sowie auch den Atributten stellt also eine Sicherheitsproblem dar, und zwar das, dein System und seine Arbeitsweise zu eraten.

Wenn ich Usern die Möglichkeit gebe, ihre eigenen Templates auf Basis eines zur Verfügung gestellten XML-Files zu benutzen, dann muss das XML-File nicht unbedingt auf die Arbeitsweise hinweisen.
Ich gebe ihnen nur die Daten, die sie so oder so sehen. Wenn ich diese dann noch einfach mit #result_i benenne, ist das meiner Ansicht nach kein Problem.

Aber natürlich macht man ansonsten Templates generell nicht zugänglich.

 

[SpecialsGuy]

Man könnte sagen: XSLT ist für XML, was CSS für HTML. (ok, das ist es nicht 100% aber auf die Details kommt's gerade nicht an, nur auf das Prinzip)
Es macht also nur Sinn darauf aufzubauen, wenn man Daten in XML vorliegen hat. Und auch dann sollte man das ganze serverseitig in eine HTML-Seite umwandeln, wofür es ja entsprechende Bibliotheken gibt. So wahrt man auch die Browserkompatibilität.

Ansonsten würde ich empfehlen für eine Webseite einfach beim HTML-Prinzip zu bleiben. XSLT/XML macht in meinen Augen erst mehr Sinn in datenorientierte Webanwendungen (z.B. wie phpmyAdmin), also da wo Daten wichtiger als Design oder Layout sind.

Übrigens, kleine Anmerkung: Kein Browser kann AJAX - das ist eh nix anderes als letztendlich JavaScript

 

[ice-breaker]

Das größte Problem hast du ja eigentlich bei diesen komplexen Templatesystemen. Nichts gegen Smarty und co. Sie sind sehr Leistungsfähig und einfach zu bedienen. Allerdings, sind das echte Parser Verbraucher. Denn ein TPL System sollte eigentlich nur das tun, was es tun sollte. Das sind Markierungen in Varibalenwerte ersetzen. Nicht mehr und nicht weniger. Alles andere erfordert das mehrfache Parsen, und das vervielfacht sich schneller man sich umsehen kann. Jedes Zusatzfuter muss so von TPL zu TPL geprüft und geparst werden.

Mein Vorschlag, und das beste was du machen kannst, bau dir ein eigenes, welches genau deinen Bedarf sätigt. So hast du optimal Leistung und Bedarf gestillt. Und das schöne an zb Smarty ist ja das es viele kennen und man daher auch in kunden-software nutzen kann und es viel plugins etc gibt, das selbstschreiben von modifikatoren in smarty (was echt simpel ist) ist einfach nur genial

Die Leistungsschwachen Verbraucher TPL Systeme sind jenige die mit implode() abrbeiten. Sie greifen nur gering auf Parserleistung zurück.

Grüsse Lukasz!

neija das was smarty an Zeit verbraucht ist seid letzten optimierungen echt gering, ich denke mal eher das ein selbstgeschriebenes Templatesystem weit mehr last benötigt, da man nicht ganz so erfahreren in optimierung ist wie die programmierer von smarty.
und für überflüssige funktionen gibt es ja auch abgespeckte systeme wie Smarty light bzw. jetzt Flat Frog
Das schöne an solchen systemen ist ja das sie weit verbreitet und bekannt sind und daher auch ohne probs in kunden-software genutzt werden kann und sich ein andere programmierer nicht erst mit der engine auseinandersetzen muss

Übrigens, kleine Anmerkung: Kein Browser kann AJAX - das ist eh nix anderes als letztendlich JavaScript

neija im Prinzip ist ajax ja eine schnittstelle (stark vereinfacht) und dann könnte man schon von unterstützung reden :biggrins:

 

[SpecialsGuy]

neija im Prinzip ist ajax ja eine schnittstelle (stark vereinfacht) und dann könnte man schon von unterstützung reden :biggrins:

AJAX ist ein Konzept, eine Bibliothek ... zur Definition als Schnittstelle reicht es da wohl nicht. Die Technologien, die AJAX benutzt gibt es schon seit mehreren Jahren (schon im IE4) und man hat sie auch vorher schon benutzt, noch bevor dieser Kunstbegriff geschmiedet wurde und jetzt alle von AJAX reden, statt z.B. von Javascript, DOM und XMLHttpRequest.

Dementsprechend sind auch "Web 2.0" und andere solche Begriffe nichts als moderne Namensgebungen, die alle auf Technologien basieren die es schon lange gibt und in erster Linie die Zusammenstellung dieser Technologien als ein Konzept wiedergeben.

 

[Johnson]

AJAX ist ein Konzept, eine Bibliothek ... zur Definition als Schnittstelle reicht es da wohl nicht. Die Technologien, die AJAX benutzt gibt es schon seit mehreren Jahren (schon im IE4) und man hat sie auch vorher schon benutzt, noch bevor dieser Kunstbegriff geschmiedet wurde und jetzt alle von AJAX reden, statt z.B. von Javascript, DOM und XMLHttpRequest.

:biggrins:

Ajax ist keine Bibliothek - es ist lediglich ein Konzept.

Übrigens: Die XMLHttpRequest-Technik wurde ursprünglich von Microsoft entwickelt und steht im Internet Explorer seit Version 5.0 als ActiveX-Objekt zur Verfügung. - Wikipedia

XMLHttpRequest ist allerdings eine API.

 

[SpecialsGuy]

Ajax ist keine Bibliothek - es ist lediglich ein Konzept.

Ein Konzept (betonte ich das nicht?), zu dem es Bibliotheken/Frameworks gibt

Es war übrigens auch im IE4 schon möglich, einiges von dem zu realisieren, was mit AJAX möglich ist, das wollte ich damit sagen. Sicherlich auf eine etwas andere ähnliche Weise, aber immerhin möglich

 

[theHacker]

AJAX ist ein Konzept, eine Bibliothek ... zur Definition als Schnittstelle reicht es da wohl nicht. Die Technologien, die AJAX benutzt[,] [...] hat [man] auch vorher schon benutzt, noch bevor dieser Kunstbegriff geschmiedet wurde und jetzt alle von AJAX reden, statt z.B. von Javascript, DOM und XMLHttpRequest.

Was ich krass finde:
Ich weiß zwar, wie AJAX funktioniert, hab mich aber noch nie mit XMLHttpRequest befasst bzw. es ausprobiert.
Doch lange bevor ich den Begriff "AJAX" zum ersten Mal gehört habe, hatte ich bereits mittels unsichtbaren IFrame zum Datentausch im Prinzip dieselbe Technik angewandt.

 

[ice-breaker]

theHacker, nicht die gleiche Technick aber das Prinzip ist ungefähr gleich, das schöne ist eben du kein I-Frame benötigst und man problemlos daten übergeben auch header bzw. post zugriffe auf den server und das echt ohne probleme

 

[theHacker]

theHacker, nicht die gleiche Technick aber das Prinzip ist ungefähr gleich[...]

Ich meinte mit "gleicher Technik", dass ich Daten zwischen Server und Client austauschen konnte, ohne dass der Besucher die Seite neuladen muss.

Mein Beispiel da war ein Schachspiel. Wurde eine Figur angeklickt, wurde ein "Bitte warten..."-Overlay angezeigt und im Hintergrund hat PHP alle möglichen Züge berechnet. War das Ergebnis da, ist das Overlay wieder versteckt worden und die entsprechenden Züge mittels CSS-Rahmen angezeigt.

 

[ABC]

Ich meinte mit "gleicher Technik", dass ich Daten zwischen Server und Client austauschen konnte, ohne dass der Besucher die Seite neuladen muss.

Bürgt aber dann auch den Nachteil, dass dein Server die eigentliche Datei abholt. Was natürlich bei protokollierungen auch nicht gerade wünschenswert ist.

Aber das ist jetzt mal nur so eine Überlegung.