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

[Johnson]

Morgen,

In letzter Zeit habe ich immer häufiger den Begriff "XSLT" gehört; und was für "Tolle Möglichkeiten das doch bietet".

Nun habe ich mich mal bei Wikipedia schlau gemacht und habe dazu nun einige Fragen:

Habe ich das richtig verstanden, dass für Templating mit XSLT die Daten per XML ausgeliefert werden und der Browser die Daten dann mittels XSLT die Arbeit "Suche & Ersetze"-Arbeit sowie das Füllen des Templates mit dynamischen Daten, die es von dem XML-Daten-Dokument bekommt, übernimmt übernimmt ?

Hattet ihr das schonmal ausgetestet und könnt von nennenswerten Performanceschüben (dadurch, dass das Templating clientseitig läuft) oder Arbeitserleichterungen sprechen ?
Ich habe mich nämlich noch nicht so mit XML beschäftigt, von daher sieht es für mich jetzt eher wie eine "Erschwerung" aus, das ganze in XML zu packen usw.

Die Beispiele finde ich echt beeindruckend (z.B. das)

Gruß

Johnson

 

[theHacker]

Benutzt selber habe ich es auch noch nicht, ich kenne also nur die SelfHTML.net-Artikel (guck dir die mal an, falls noch nicht geschehen).
So wie ich das sehe, ist XSLT nur interessant, wenn du die Daten eh schon im XML-Format geliefert bekommst, bzw. in diesem Format leichter handhaben kannst.

 

[veers]

Wir verwenden an der Arbeit des öfteren XSLT um aus XML Dateien XHTML zu generieren für den Client. Läuft dann jedoch Server seitig... XSLT ist definitiv mächtig und auch nützlich um XMLs zu Konvertieren. Kann dir jedoch auch sagen dass es teilweise ziemlich tricky ist (vorallem wenn man nicht wirklich fit ist..).

 

[Johnson]

Danke erstmal für die schnellen Antworten

@tH: Den Artikel auf Selfhtml knöpf ich mir noch vor.

@Veers: Ich hatte besonders beim Nachladen von Daten an XSLT gedacht. Dann muss ich keinen HTML-Code neu liefern, sondern nur die Daten - und das ohne ewiges JavaScript-Gefummel.

Gruß

 

[tleilax]

Ich würd's auch nur anwenden, wenn ich eh schon XML-Dateien vorliegen habe. Ein Websystem, das nur XML ausliefert und das dann per XSLT darstellen lässt, wäre zwar schick, aber in meinen Augen viel zu kompliziert. Solange es nur um die Darstellung von Daten geht, kein Problem, aber sobald man Userinputs hat, wühle ich mich lieber durch HTML als durch XSLT-Dateien.

Und wie veers schon sagt - man muss mich wirklich fit in dem ganzen X-Kram sein. XML, XSLT und XPath sind ja vermutlich nur die Mindestanforderungen. Wobei XML an und für sich ja nicht schwer ist, aber das Umfeld ist am Anfang leicht erschlagend mit seinen Schemata oder DTDs.

 

[Johnson]

Und wie veers schon sagt - man muss mich wirklich fit in dem ganzen X-Kram sein. XML, XSLT und XPath sind ja vermutlich nur die Mindestanforderungen. Wobei XML an und für sich ja nicht schwer ist, aber das Umfeld ist am Anfang leicht erschlagend mit seinen Schemata oder DTDs.

Deswegen hab ich mich auch noch nicht näher mit beschäftigt

Ich glaub ich schau mir vorher lieber noch nen paar AJAX-Klassen an - vielleicht ist´s damit ja besser zu lösen mit dem Ersetzen von Elementen

 

[ice-breaker]

Ajax ist sicherlich einfacherer, ist ja was ganz anderes als XSLT^^

und ich würde mir nicht unbedingt eine AJAX-Klasse raussuchen sondern selbst deine Klasse zusammenschreiben, denn ich muss ganz ehrlich sagen für ajax brauchst du 4 codezeilen und du hast schon eine asynchrone verbindung zu einem server, da sind die frameworks meiner meinung einfach zu überladen mit funktionen. falls du nen bisel rat in ajax brauchst, kannste dich in icq melden

Edit: foreach bieten dir auch templatesysteme wie smarty

 

[Johnson]

und ich würde mir nicht unbedingt eine AJAX-Klasse raussuchen sondern selbst deine Klasse zusammenschreiben, denn ich muss ganz ehrlich sagen für ajax brauchst du 4 codezeilen und du hast schon eine asynchrone verbindung zu einem server, da sind die frameworks meiner meinung einfach zu überladen mit funktionen. falls du nen bisel rat in ajax brauchst, kannste dich in icq melden

Okay, danke - falls ich irgendwo festhänge melde ich mich mal!

Ich werde mir zu diesem Thema jetzt warscheinlich diesen Überblick bestellen - von diesem Autor hab ich auch schon das ganz gute JavaScript-Buch gelesen (wenn auch noch nicht ganz - JavaScript kann ziemlich demotivierend sein) und die Bewertungen bei Amazon sind auch besser wie die bei den anderen AJAX-Büchern, die ich gesehen hab ..

Edit: foreach bieten dir auch templatesysteme wie smarty

Ja, allerdings ging es mir besonders um die Möglichkeit dies den Client berechnen zu lassen.

 

[ice-breaker]

ich würde dir sehr das Buch AJAx von Galileo Computing (hab ich auch) ans Herz legen, es kostet etwas mehr aber behandelt wirklich ALLE themen von ajax, sogar wie man bookmarks im ie/gecko-browser macht und wie man vor/zurück/reload button richtig in ajax einbindet, eigentlich ist alles vom thema ajax drin, sowie wirklich massig beispiele und noch einige frameworks

 

[Johnson]

ich würde dir sehr das Buch AJAx von Galileo Computing (hab ich auch) ans Herz legen, es kostet etwas mehr aber behandelt wirklich ALLE themen von ajax, sogar wie man bookmarks im ie/gecko-browser macht und wie man vor/zurück/reload button richtig in ajax einbindet, eigentlich ist alles vom thema ajax drin, sowie wirklich massig beispiele und noch einige frameworks

Thx, ich schau mir jetzt erstmal "AJAX. schnell + kompakt" an, und wenn mein Wissensdurst dann nicht gestillt ist, dann kommt dein Buch (obwohl die Rezensionen bei Amazon btw nicht so gut waren - aber das will ja nichts heißen)

 

[ice-breaker]

rezensionen? mal gugn, also wenn jemand nicht ajax von javascript unterscheiden kann (steht deutlich drin) tut er mir leid^^ ich glaube die leute habe nicht ganz verstanden was ajax ist, denn das hätten sie schon nach der einleitung raffen müssen, und das ajax nur aus ~3 funktionen mit ein paar eigenschaften (glaube 5) besteht wird im ersten kapitel behandelt

aber der preis von deinem buch ist echt gut, da bestell ich mir mal das RegExp buch^^ dauerhaft bcher für 30-40€ (auch wenn sie es wert sind) wird mit der zeit teuer

 

[Johnson]

rezensionen? mal gugn, also wenn jemand nicht ajax von javascript unterscheiden kann (steht deutlich drin) tut er mir leid^^ ich glaube die leute habe nicht ganz verstanden was ajax ist, denn das hätten sie schon nach der einleitung raffen müssen, und das ajax nur aus ~3 funktionen mit ein paar eigenschaften (glaube 5) besteht wird im ersten kapitel behandelt

Dito, sowas ist echt mehr als peinlich ...

aber der preis von deinem buch ist echt gut, da bestell ich mir mal das RegExp buch^^ dauerhaft bcher für 30-40€ (auch wenn sie es wert sind) wird mit der zeit teuer

Ich lass mir seit Ewigkeiten immer Büchergutscheine schenken - und die sind immer schnell klein

Wenn wir gerade schon beim OT sind:

Hat zufällig jemand dieses
Buch schon gelesen ? Laut den Rezensionen vom (glaube ich - kann mich nicht mehr ganz genau erinnern) phpmag und phpforum.de echt lohnenswert, aber hat da jemand schon Erfahrungen ? Die Themen, die in den Rezensionen / der Produktbeschreibung genannt werden hören sich für mich bis auf einige sehr nach den absoluten Grundlagen an; die man schon X mal gehört / gelesen hat.

 

[ice-breaker]

Hat zufällig jemand dieses
Buch schon gelesen ? Laut den Rezensionen vom (glaube ich - kann mich nicht mehr ganz genau erinnern) phpmag und phpforum.de echt lohnenswert, aber hat da jemand schon Erfahrungen ? Die Themen, die in den Rezensionen / der Produktbeschreibung genannt werden hören sich für mich bis auf einige sehr nach den absoluten Grundlagen an; die man schon X mal gehört / gelesen hat.

"Es vermittelt auf verständliche Art und Weise ein wichtiges Grundwissen, um seine Webanwendungen vor Angriffen zu schützen."
Aus den Amazon-Rezensionen

 

[Johnson]

"Es vermittelt auf verständliche Art und Weise ein wichtiges Grundwissen, um seine Webanwendungen vor Angriffen zu schützen."
Aus den Amazon-Rezensionen

Der eine spricht von Grundlagen, der andere von "sehr umfassend".

"inhaltlich ist das buch absolut top. sehr umfassend, habe sehr viel dazu gelernt."
Aus den Amazon-Rezensionen

 

[ice-breaker]

k, mach me eben nen OT-Thread daraus^^

was willst du bei dem thema schon groß vermitteln?
ich denke was wirklich neues wirst du dort nicht finden.
vllt nochmal das du nicht direkt parameter aus $_GET includen darfst

 

[ABC]

Morgen,

In letzter Zeit habe ich immer häufiger den Begriff "XSLT" gehört; und was für "Tolle Möglichkeiten das doch bietet".

Nun habe ich mich mal bei Wikipedia schlau gemacht und habe dazu nun einige Fragen:

Habe ich das richtig verstanden, dass für Templating mit XSLT die Daten per XML ausgeliefert werden und der Browser die Daten dann mittels XSLT die Arbeit "Suche & Ersetze"-Arbeit sowie das Füllen des Templates mit dynamischen Daten, die es von dem XML-Daten-Dokument bekommt, übernimmt übernimmt ?

Hattet ihr das schonmal ausgetestet und könnt von nennenswerten Performanceschüben (dadurch, dass das Templating clientseitig läuft) oder Arbeitserleichterungen sprechen ?
Ich habe mich nämlich noch nicht so mit XML beschäftigt, von daher sieht es für mich jetzt eher wie eine "Erschwerung" aus, das ganze in XML zu packen usw.

Die Beispiele finde ich echt beeindruckend (z.B. das)

Gruß

Johnson

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 du das parsen wegfallen lassen willst, gibt es auch die möglichkeit templates zu includieren statt zu parsen. Diese Daten in einem Buffer zu speichern und zum Schluss des Scriptes einmal auszugeben.

Die Herausgabe aller Daten, die auf dein Script zurückführen, veraten deine Vorgehensweise.

Im punkto 2 musst du auch noch eines bedenken. Die Rechenleistung des Clienten steigt drastisch. Heut zu tage reicht ein JS nicht. Es werden hunderte Bildchen ein paar JS und CSS Codeteilchen, vermutlich eine SWF Datei die noch an andere Daten dockt an den Clienten gesendet. Nich umsonst kann eine schön designte Seite locker 4 MB Speicher verfuttern. Bei einem 64er macht das nichts, aber wenn du mal an einen Rechner sitzt, der älter wie 2 Jahre ist kannst du trotz DSL 6000 zuschauen, wie die Seite sich aufbaut. Jetzt noch kommen Templates hinzu? Dann komm wieder so ein FIFO templates blocken etc...

Sinn macht es also keinen großen. Es entlastet den Webserver. Und für wirklich große Seiten wie ebay Amazon etc.. eine nette Lösung. Aber für den Otto Normal Webmaster in meinen Augen Schwachsinn. Die meiste Leistung deines Servers wird in deiner DB und beim upload des Servers verbraucht. Wenn der Parser pro Abruf 20 Templates parsen muss, ist das ein kleiner Witz gegen eine Datenbankabfrage.

Mach mal den Test. Mach 2 PHP Dateien. Parse mal in einer Seite 20 aufändige Templates. Und in der 2ten Datei machst du nur die Verbindung einer DB trotz localhost. So ein Benchmark kann man sich schnell machen. Du wirst sehen, die DB hängt hinterher.

Kurz rentabel nur für riesige Projekte mit mindestens 10tsd Besucher am Tag. Belastend für den Clienten, der den (Kram) erstmal verdauen muss. Die Qualität der Seite sinkt.

Und da wäre noch punkto 3. Bis das jeder Browser abpeilt, hast du schöne Auslieferungen an Browser die es nicht verstehen möchten. Dann wird wieder in der technik getrixt und gedreht, bis es wieder passt. Natürlich mit der Leistung des Verbrauchers. Aber das allein ist auch egal. Ich bin der Meinung, es gibt im Netz genug zu tun. Und ein Guru oder Freak braucht das Rad nicht neu erfinden.

Am Ende hat man wieder ein "schön hier ist was neues" Produkt geschaffen. Aber ist das nützlich ist die entscheidende Frage.

 

[ice-breaker]

Kurz rentabel nur für riesige Projekte mit mindestens 10tsd Besucher am Tag. Belastend für den Clienten, der den (Kram) erstmal verdauen muss. Die Qualität der Seite sinkt.

und wir haben ein weiteres Problem der Browser-Kompatibilität

 

[ABC]

und wir haben ein weiteres Problem der Browser-Kompatibilität

richtig! hatte ich eben dazueditier!

 

[ice-breaker]

da fällt mir folgendes zu ein:
wieviele jahre gibt es xml und wielange hat es gebraucht bis man es wirklich nutzte?
wieviele jahre unterstützt der ie (und teils andere browser auch) ajax und wann begann man es zu nutzen?

die kompatibilität ist ein großer schwerpunkt und oft ist diese erst jahre nach einführung einer technick vorhanden (aber xslt ist eigentlich sehr alt)

 

[MrToiz]

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