Template-Engine

Verwendet ihr eine Template-Engine? Wenn ja, welche? und habt ihr diese selber geschrieben oder schon eine fertige heruntergeladen?

Ich benutze freemarker.

Ich hab mir vor Ewigkeiten mal selbst eine einfache Templateengine zusammengebastelt (Ich seh grad: 2003 wars). Einmal musste ich etwas nachprogrammieren, aber ansonsten bin ich immer damit ausgekommen.

Wie bist du da vorgegangen?

Ich habe mir jeweils ein Arrayformat ausgedacht für einfache Ersetzungen und für "Loops", also Abschnitte im Template, die wiederholt werden, aber mit anderen Inhalten bestückt werden.
Dann für jedes Format jeweils eine Funktion geschrieben, die diese Ersetzungen und Wiederholungen auf das Template ausführen.

Ich versteh das mit den Loops nicht, wie ich die Speichern soll und dann noch das richtige ersetzen.

Dann nimm dir eben eine fertige.

{row.VAR}

Das schreibst du in dein Template und suchst dann mit ner Funktion nach solchen Blöcken und ersetzt sie durch folgendes:

for ( $i = 0 ; $i < sizeOf($blocks['row']) ; $i++ ) {
  echo '
    '. ( ( isset( $blocks['row'][$i]['VAR'] ) ) ? $blocks['row'][$i]['VAR'] : '' ) .'';
}

So mal grob umschrieben, soll jetzt nix fertiges sein, nur ein Denkansatz.

Ah, danke. Die Funktion sizeof() kannte ich bis jetzt noch nicht, bzw. ist nur ein Alias für count() (Kannte ich auch noch nicht).

sizeOF ??
soll da nicht size0(null)F stehen ?

ich nutze Savant 3 und bin sehr zufrieden damit.
ist eben nicht so aufgebläht wie smarty o.ä. und wenn man mal kurz was ändern will ist das auch np .. alles super kommentiert

Wenn du was sehr fixes suchst und auch die Logik da lassen willst wo sie hingehört, dann ist php-templates das richtige.

Ich hab mir meine eigene geschrieben.. inzwischen schon Version 2 welche dank 2-facher Cachefunktion nun auch schön schnell und umfangreich ist.

Eigenentwicklung auf Block-Basis.

Ich verwende Smarty. Bietet alles was man braucht.
smarty.php.net/

Original von progs
Ich verwende Smarty. Bietet alles was man braucht.
smarty.php.net/

Smarty ist viel zu überladen.
Ich überlege gerade ob ich mit XLST arbeiten soll. Was haltet ihr davon?

Original von TheHawk

Original von progs
Ich verwende Smarty. Bietet alles was man braucht.
smarty.php.net/

Smarty ist viel zu überladen.
Ich überlege gerade ob ich mit XLST arbeiten soll. Was haltet ihr davon?
Derzeit viel
Ich habe den kompletten Neuentwurf des Spiels mit XSLT umgestellt, und ich komme damit gut klar. Der Processor ist in PHP integriert, dementsprechend sehr flink. In Tests war ich bei einem "Liverendern" sogar schneller als bei Smarty (keine Optimierung von Scripts).
Theoretisch könnte man ein System entwickeln, welches Teilbereiche von einer Seite cached, aber das war mir zu anfwendig.
XSL hat einige Vorteile, ich habe sogar mal mit dem Gedanken gespielt, später eine Just-4-Fun XUL-Anwendung zu bauen - alles machbar.

Meine Frage. Soll man die Seite mir PHP-XLS rendern oder dies den Browser erledigen lassen?

Du solltest nicht davon ausgehen, dass der Browser das rendern unterstuetzt, darum render das lieber serverseitig.

Original von TheHawk
Meine Frage. Soll man die Seite mir PHP-XLS rendern oder dies den Browser erledigen lassen?

Prinzipiell geht clientseitiges Rendern. Der IE5.5 konnte bereits XSL, der IE6 kann den XSLT-1.0 Standard (liegt u.a. daran, das MS nicht ganz unbeteiligt an diesem Standard war). Imho das einzige Sorgenkind ist der Opera, denn der unterstützt XSL prinzipiell erst ab 9.0.
Ich würde dennoch derzeit ein serverside processing empfehlen, weil du dir nicht sicher sein kannst, ob dein Gegenüber XSL "hat". Spätestens, wenn du es multiplattformmäßig aufziehen willst, wirds Probleme geben (kann mir nicht vorstellen, das die Webhandys schon einen XSLT-Processor integriert haben).
Was man machen kann: Du stellst es dem Benutzer frei, ob er client oder serverside machen will.. man kann das durchaus als Geschwindigkeitsvorteil "werben". Viel ist es nicht, aber der Client wird es wahrscheinlich schneller gerendet kriegen als der Server. Das funktioniert natürlich nur dann, wenn die XML-Daten auch kleiner/gleich sind als das Resultat.. sonst wird das wahrscheinlich nicht viel bringen.

man könnte doch auch einfach eine Browserweiche einbauen.

oder besser mit Javascript herausfinden ob dies unterstützt wird (falls möglich) und dann den Server anfunken was zu tun ist.

Der Vorteil von serverseitig wäre ich könnte einmal in XHTML und einmal WML ausgeben.

Ich unterbreche ungern diese Diskussion, aber dank diesem Thread schreib ich jetzt auch ein eigenes Templatesystem. Wahrscheinlich seh ich den Wald vor lauter Bäumen nicht, aber ich steh vor einem Problem dass ich im Moment einfach nicht lösen kann...
Also, ich möchte dass durch den Text "[[VAR:Foo]]" im Template die Variable mit Namen Foo ausgegeben wird.
Gut, wie ich an den Namen der Variable komme ist mir klar. Wie ich diesen ausgebe auch.

preg_replace('=\[\[VAR.*)\]\]=Uis', '\1',$temp);

Gibt natürlich "Foo" zurück. Doch wie kann ich den Namen jetzt in einer Funktion weiterverwenden? Sowas funktioniert nicht:

preg_replace('=\[\[VAR.*)\]\]=Uis', $this->readVar('\1'), $temp)

Hier wird jetzt \1 als Parameter übergeben was natürlich nicht Sinn der Übung ist.
Helft mir. Ich verzweifle
(Was mir beim Lesen gerade auffält: Es kann zu Missverständnissen kommen! Ich will nur eine einzige Variable zurückgeben, kein ganzes Array!)

eval('$fooinhalt = $'.$temp[1]);

Original von friedenspanzer
Doch wie kann ich den Namen jetzt in einer Funktion weiterverwenden? Sowas funktioniert nicht:

preg_replace('=\[\[VAR.*)\]\]=Uis', $this->readVar('\1'), $temp)

preg_replace('=\[\[VAR.*)\]\]=Uise', '$this->readVar(\'\1\')', $temp)

Ich empfehle die Templates nicht bei jedem Aufruf zu parsen sondern nur einmal in PHP-Scripts zu kompilieren und dann nur noch via include() einbinden. Smarty ist zwar ein nutzloses Monster aber da hat es wenigstens etwas richtig gemacht.
Vorteile:
1. Template muss nicht bei jedem Aufruf geparst werden. Regexes werden schnell langsam wenn sie mal umfangreicher werden. Einmal parsen und danach übernimmt das immer der PHP-Interpreter, der deutlich schneller ist. Oder man verzichtet einfach auf den Unsinn mit Templateengines für PHP und schreibt die Templates gleich in PHP. Die ganze Sprache ist schliesslich nur eine aufgebohrte Templateengine ...
2. Bei Tools wie Accelerator werden PHP-Templates ebenfalls in den Bytecodecache genommen. Anders als Templates die von anderen PHP-Scripts bei jedem Aufruf neu geparsed werden. Nochmal eine Performancesteigerung (aus dem Grund würde ich auch Konfigdateien, Sprachdaten usw. immer in Scripts kompilieren).

Original von Klaus
oder besser mit Javascript herausfinden ob dies unterstützt wird (falls möglich) und dann den Server anfunken was zu tun ist.

Und warum JavaScript nutzen, wenn unnötig? Useragent ist dein Freund.. im Zweifel immer einen Fallback einbauen. Das muss man bei der "JS-Lösung" auch.

Original von TheHawk

Der Vorteil von serverseitig wäre ich könnte einmal in XHTML und einmal WML ausgeben.
Jo. Genau deswegen. Allerdings stellt sich mir die Frage, ob WML überhaupt noch notwendig ist.. können die meisten Geräte nicht eh XHTML?
Ich würde in diesem Falle nämlich sonst so vorgehen: Entweder das normale XHTML-Dokument, mit einer anderen CSS (Geräte die nicht CSS können, sehen da eh meine SEMANTISCHE Struktur) oder aber ein "XHTML"-Light Template.. also mit keinen Querverweisen, keine Sidebar, ohne Bilder, etc..

Original von knalli

Original von Klaus
oder besser mit Javascript herausfinden ob dies unterstützt wird (falls möglich) und dann den Server anfunken was zu tun ist.

Und warum JavaScript nutzen, wenn unnötig? Useragent ist dein Freund.. im Zweifel immer einen Fallback einbauen. Das muss man bei der "JS-Lösung" auch.
weil es einfacher ist zu überprüfen ob es das Objekt der Begierde tatsächlich gibt anstatt rumzuraten ob der Browser es eigentlich unterstützen müssten. Außerdem kann man den Useragent angaben nicht trauen und man muss bei neuen Browser noch was ändern usw.

In Tests war ich bei einem "Liverendern" sogar schneller als bei Smarty

ich habe mir gerade selber ein paar tests mit xslt und smarty gemacht, bei mir war smarty um ca. 50 % schneller?? ich habe mal die test-files als anhang reingetan. jetzt haben schon 2 leute (jemand aus einem anderen Forum) behauptet das xslt schneller ist, aber bei mir hat sich das nicht bestätigt??

Jo.. das ist klar, das deine Lösung da rumlahmt
DomDocument ist so das mieseste, was du in PHP machen kannst.
edit: Bei meinem unten angefügten Test hatte ich (bei mehr Daten als bei dir *glaub*) teilweise über 50% alleine appendChild()-Stress. Herausfinden kann man sowas mit APD - einen kleinen Überblick verschafft woodyworkers Blogeintrag zu diesem Thema (man suche in der GN Blogsphäre). Alternativ in Google, das habe ich gemacht.
Zusätzlich muss ich zugeben, das ich aber auch nicht so ein Riesentaraa um den XSL-Prozessor gebaut habe.. ich müsste zwar noch einen "Processing-nicht-erfolgreich"-Abfang einbauen, aber im großen und ganzen habe ich XSL XSL gelassen.. die hauseigenen Methoden fand ich eigentlich ausreichend. Alle Angaben sind im XSL möglich..
Angefügt:
Ich hab das vor einiger Zeit, als ich nach der Effektivität geforscht habt (naja, das klingt jetzt was überheblich..) das hier als Resultat gehabt: www.knallisworld.de/blog/2006/06/15/xslphp-templating/
Nun muss ich dazu sagen, das der Editor mir beim Publishing leider die Sonderzeichen durcheinander gebracht hat, deshalb sind die Codeauszüge (wie ich gesehen habe) nicht wirklich gut - aber das Prinzip sollte klar sein.

danke für deine antwort (und den link).
da werde ich wohl eine funktion schreiben müssen, die ein array mit daten in ein string mit xml drin verwandelt.

Wie sieht das mit der SimpleXML Klasse aus? Ist die auch so langsam wie DOMDocument oder schneller?

Original von TheHawk
Wie sieht das mit der SimpleXML Klasse aus? Ist die auch so langsam wie DOMDocument oder schneller?

Schneller.. aber schneller als die Sache mit einem XML-String ist nix. Das betrifft vorerst nur PHP, ich denke nämlich nicht, das man diese Vergleiche irgendwie leichtfertig auf andere Sprachen wie Java umführen kann..
Kurze Vergleichswerte (leider nicht ganz im Bezug zu den Zahlen im Beitrag): XSLT mit XML-String (1.19), XSLT mit DOMDocument (4.71) und XSLT mit SimpleXml (2.44)

hmm.
bei mir braucht xsl 1.45 im durchschnitt.
wobei smarty im durchschnitt 0.79 braucht.
also ich bleibe bei smarty. wobei xsl auch cool gewesen wäre.

Original von planetenkiller
@knalli
kannst du mir zeigen wie du das mit dem xml generieren gemacht hast?
ich komme bei mir nicht auf 1.19 im gesamten.

projects.knallisworld.de/stresstest/
das XSL ist hier: projects.knallisworld.de/stresstest/PerfXslTest.xsl
Ich hab grad mal durchgesehen, ist auch nicht ganz performant, da die Regeln //page überflüssig sind; ein /page hätte ausgereicht.
Und das Transformieren.. nun ja, wie ich gesagt habe: Ich habe mich hier um das wesentliche beschränkt: proc->importStyleSheet(xsl), proc->transformToXML(xml)
PS: Der Grund, warum einige Zeiten unterschiedlich sind: Ich habe nachträglich einige Random-Funktionen entfernt oder "gemildert", weil sie das Testergebnis zu sehr beeinflussen würden. Im Großen und Ganzen sind die Größenordnungen aber so - und die Werte unterscheiden sich manchmal nur um 0.01 nach oben oder unten.. (abwechselnd, mehrmals laufen gelassen).

wow, ich stelle mein BG sofort in XSL um .
ich habe gerade nochmal testes gemacht:
Auf meinem PC(WIN xp):
Smarty: 1.5
XSL: 0.22
Anderer PC bei mir(Linux Debian sarge):
Smarty: 0.79
XSL: 0.37
seit ich die Klasse nicht mehr verwende und xsl im einfachen Style benutze ist xsl richtig schnell. Das gefällt mir.

Ich bin dabei.. ich werd wahrscheinlich, wenn ich fertig bin.. mich mal aus FUN an XUL machen. Also nicht produktiv, sondern.. weils geht.