Tidbits Template Class (habe ich selbst gemacht!)

Ja kein Problem, ich wollte nur sicher gehen, das ich nicht einen Fehler gemacht habe. Wenn du die Fehler beseitigt hast mal melden, gefällt mir nämlich die Template Engine

Ich kann ja mal versuchen den Fehler auszumerzen wenn ich ihn denn finden sollte

Ich interessiere mich auch für diese Template Class. Hab beim lesen vorhin garnet auf das Erstell-Datum geachtet.
Werde die Klasse bei Gelegenheit auch mal testen

Ich hab mir inzwischen eine eigene Template-Klasse gebastelt
Diese verwende und teste ich auch schon in einem eigenen Projekt

Hi!
Ist zwar mitlerweile schon ein halbes Jahr her seit der letzten Antwort, hab die template-Klasse aber erst jetzt endeckt und bin finde sie eigentlich ganz gut!
Gibt es da mitlerweile ne neue Version oder eine die einwandfrei funktioniert?
Danke!
Gruß Felix

Nein, ich habe daran nicht mehr weiter gebastelt, hatte irgendwann einen Festplattencrash und die neuste Version noch nicht gesichert. Danach ist mir die Lust vergangen und ich habe für mein Software-Projekt Smarty genommen. Vorläufig ist von mir aus auch nicht mmit neuen Versionen zu rechnen, vielleicht werde ich für meine andere Software eines Tages nochmal schreiben. Wann und ob überhaupt sowas stattfinden wird, kann ich aber im Moment noch nicht sagen.

Wenn wir gerade dabei sind: Da ich auch mit den Gedanken spiele, neben einer komplexen Datenbankklasse mir auch einmal eine komplexe, eigene Templateklasse ala Smarty zu programmieren (für mich selbst), die Frage, was kann den, Fabchan, deine Templateklasse? Was hast du für Erfahrungen, was eine Templatecklasse haben sollte? Ich rede jetzt nicht von simplen wie if, elseif, else, eine Ausgabe und eine PHP-Cache.

@frederic:
Seine Template-Klasse (ich beziehe mich auf die ältere Version 1.02(?)) war nach einem guten Konzept aufgebaut und recht einfach im Code. Ich habe mir eine eigene geschrieben, die auf dem gleichen Prinzip beruht.
Je nachdem welchen Weg du einschlägst, wirst du auf verschiedene kleinere oder größere Probleme stossen, die es zu lösen gilt.
Ich habe einige Gehversuche gemacht und fremde Projekte angeschaut, bis ich den für mich passenden Weg gefunden habe.

@Fabchan:
Solltest du diese ältere Version noch haben, so stelle doch einfach diese mal bereit. Ich fand diese sehr lehrreich und gut, wenn auch einige für mich wichtige Funktionen gefehlt haben.


Meine TPL-Klasse ist leider völlig undokumentiert und inzwischen auch nicht mehr im Betrieb, da ich mein eigenes Projekt aus Zeitgründen momentan auf Eis gelegt habe. Vielleicht setze ich mich mal irgendwann (...) an die Doku und stelle diese doch bereit...

Entschuldigt, dass ich bisher nicht wieder geantwortet habe, stehe im Moment etwas unter Zeitdruck, vielleicht habe ich nächste Woche zeit, mich nochmal darum zu kümmern.

Ich kenne das Problem mit dem Zeitdruck, also keine Panik

mal ne andere frage..
ich nutze auch eine eigene simple template klasse, die weit weniger kann als deine (trenne halt gerne html und php)
aber ich hab letztens if-else abfragen eingebaut
klappt wunderbar, jedoch kann ich sie nicht verschachteln. geht das bei deiner klasse??
mfg

Björn: Entweder du übersetzt die If-Strukturen des TPLs in PHP und führst es anschließend mit eval() aus oder du schreibst dir einen Parser, der den Code Zeichen für Zeichen nach If's durchsucht (hab ich mal gemacht: sehr zeitaufwendig und komplex).

Ja, das Problem kenne ich. Verschachtelte Tags zu erkennen erfordert etwas mehr Aufwand, mit regulären Ausdrücken allein ist das nicht lösbar. (Jedenfalls nicht einfacher als ohne.) In meinem BBCode-Parser sowie meiner Template Engine habe ich daher einen zweiteiligen Ansatz verfolgt: Zuerst wird in einer normalen (weitestgehend optimierten) Schleife die Eingabe auf interessante Stellen durchsucht, in diesem Fall die Tags oder z.B. if/endif-Anweisungen, und danach wird jede Stelle einzeln analysiert und ggf. mit regulären Ausdrücken in die Zielsprache konvertiert (hier HTML bzw. PHP). So kann man gezielt auch die Verschachtelung der Anweisungen prüfen und im Fehlerfall reagieren, bevor es PHP oder der Browser (auf meist recht brutale Weise) tun. Falls es dich interessiert, kannst du dir den Code in einer etwas älteren Version ja unter http://px.no-ip.com/proj/ute/ mal anschauen. Die aktuellste Version hab ich in meinem Forum (siehe Signatur) verbaut.

@Björn:
Geht sowohl bei seiner als auch bei meiner Klasse
Der Code wird immer erst in php gewandelt und, sofern gecacht werden soll, in eine Datei geschrieben.
Somit wird beim ersten Aufruf des Templates der geparste Code mit eval ausgeführt und das zweite mal einfach die Cache-Datei includet.

so ist es bei mir auch es geht ja auch mehr ums verschachteln..

@eBoy: Ich sehe gerade, dasss Version 1.02 auf der ersten Seite dieses Themas ist, leider ist der Parser für IF-Konditionen noch nicht wirklich ausgereift und teilt diese nur anhand von Leerzeichen in mehrere Teile auf. Das war nur als vvorübergehende Lösung gedacht, um erstmal wieder was online zu stellen, aber ich glaube, in Version 1.03 habe ich einen besseren Parser für Ausdrücke. Hinzu kommt noch, dass Version 1.02 mit regulären Ausdrücken arbeitet und ich muss selber zugeben, dass die Methode von LonelyPixel mit dem Zeichen für Zeichen durchgehen um einiges besser ist.

Das mit dem Parser ist übrigens auch im vBulletin 3 ganz gut gelöst, also wer eines besitzt, sollte sich ruhig mal mit dem Quelltext etwas befassen!

Ich werde wohl doch mal meine herauskramen und dokumentieren, da sollte das alles funktionieren und der Code verständlich sein

Template-Parser sollte fehlerfrei funktionieren und die Dokumentation habei ich mal grob erstellt, jedoch muss ich noch einen rechtlichen Hinweis/ Copyright einfügen und habe da bisher noch keinerlei Erfahrung, wie man das formuliert bzw. was da alles drinstehen sollte...

hrrmmmhum. *räusper* *staubwegwedel*

Ich stelle das hier jetzt einfach mal zur Diskussion:

http://www.phpguru.org/static/templating.html

Ich machs jetzt nur noch so, obwohl mir die Entwicklung von geeigneten Parsern für Templates 'n Heidenspaß gemacht hat. Aber tatsächlich hat die hinter dem Link beschriebene Vorgehensweise unbestreitbar was für sich.

Leider scheint der Autor nicht zu wissen, dass die Schreibweise mit <? und ?> als deprecated gilt und somit ist der Spaß aus Sicht von PHP 5 sehr unsauber, auch wenn man sagen muss, dass es net verkehrt ist. Das beste Beispiel, für eine "PHP-Template-Engine" ist meiner Meinung nach WordPRess, die benutzen auch einfach PHP-Code und es funktioniert wunderbar, allerdings nicht so:
sondern eher so:
Und dann muss man sich schon fragen, ob man nicht doch lieber {$post.author} oder irgendwas ähnliches schreibt....

Natürlich, jeder nach seiner Fasson. Vorteile liegen jedoch auf der Hand: Bei vernünftiger Kapselung braucht man so

1) nicht schon wieder ne neue Dreckssprache zu lernen
2) sich um Performance keine (größeren) Sorgen zu machen
3) sich nicht darum zu scheren, wer die Sachen nach einem pflegt: Jeder, der PHP mindestens im Spaghettistadium beherrscht, kommt auch damit sofort ohne nennenswerten Einarbeitungsaufwand zurecht
...

Deprecated ist da eigentlich nichts. Leider ist der einzige Nachteil der "faulen" Schreibweise, dass das ganze nicht mehr wohlgeformt nach XML-Ansprüchen ist. Soweit ich weiß ist die Verwendung von <?PHP ?> auchd er einzige Weg, wenn man seine Scripte PEAR-tauglich halten will.

Ich denke aber mal, dass bei der Verwendung von "richtigen" Templatesprachen (es sei denn man baut auf Java-ähnliche Taglibs, die wiederum XML-Konform sind, aber meistens den Nachteil einer grottigen Performance haben) da in Einzelfällen noch viel mehr Probleme auftauchen können.

Außerdem: Wir reden von Templates, nicht von Skripten. Und selbst wenn man die "lange" Schreibweise bevorzugt, hindert einen ja nichts daran, diese auch zu verwenden.

Und selbst wenn ich fauler Hansel mal über meine <? ?> stolpern würde, dafür gibts ja immer noch S+R

Naja, wie gesagt, ich wollte das einfach einmal zur Diskussion stellen, ich finde jedenfalls, dass sich die ganze Sache bis jetzt für mich nur gelohnt hat. Nie mehr Templatewuseleien

Ich habe meine eigene kleine Klasse, die vom Prinzip her der von Fabchen's älteren Version nicht unähnlich ist und halte das für eine sehr gute und saubere Lösung. Ich mag es nicht php-Code (logischerweise in php-Tags) in "HTML-Dateien" stehen zu haben.
Grundsätzlich: Jedem das seine
Ich will auch kein Smarty (aufgebläht) oder XML (nochwas zu lernen), deshalb bleibe ich bei php und html

Als ich meine Template-Lib entworfen hab, hatte ich einen ganz guten Artikel zur Vorlage, der mir was über den Sinn und die Aufgaben von Templates erzählt hat, und dessen Autor am Schluss auch PHP verwendet hat. Mag ja sein, dass das schön ist, aber wer PHP kann, wird sich nicht schwer tun, ähnliche Sprachen zu lernen. Es geht hier ja nicht um universelle Sprachen wie Japanisch oder Vietnamesisch mit zigtausend Symbolen und feinen Variationen, vielmehr um vielleicht 20 Vokabeln die man größtenteils bereits kennt. Außerdem sehe ich in der Erschaffung einer neuen Sprache die Möglichkeit, diese genau auf den Einsatzzweck zu optimieren. Ich habe z.B. Konstrukte eingeführt, mit denen man ganz einfach durch eine Liste laufen kann, ohne danach ständig den selben Variablennamen zu wiederholen (foreach ohne Laufvariable). Außerdem wird man bei PHP-Templates wohl garantiert auch nicht ohne Einarbeitung auskommen. Man muss in jedem Fall nachschauen, wie die Variablen heißen, wie sie organisiert sind (Arraystrukturen, Objektmethoden etc.) und vielleicht noch wie man sie verwenden sollte (Coding Conventions). Ob ich das in PHP oder <MyTemplate> mache, dürfte weitestgehend egal sein. Da anspruchsvolle Template-Systeme direkt in PHP übersetzen und zwischenspeichern, besteht nach diesem einmaligen Aufwand kein weiterer Performanceunterschied. Es entscheidet allein der Nutzen und die Effizienz der Sprache. Hier sehe ich individuelle Sprachen, oder zumindest spezielle Templatesprachen, klar im Vorteil.

Ui xml ist xml kannste ruhig lernen, das ist ne ziemlich feine Sache... va, wenn man "mal schnell" Dokumente in HTML umwandeln will... XSL als "Templatesprache" allerdings ist schon ein wenig umfangreicher, das stimmt schon.

Wenn man tatsächlich nur ein paar Kontrollstrukturen und Variablenplatzhalter braucht, sehe ich den Einsatz einer Templatemaschine tatsächlich nicht ein. Mittlerweile aus der Erfahrung jedenfalls nicht mehr. Wenn man sich diverse OS und auch kommerzielle CMS anschaut, bekommt man das kalte Gruseln, weil tatsächlich fast jeder auf andere (eigene) Sprachen setzt, die im Grunde - und da hast du wohl recht - immer wieder dasselbe machen .

Das "feinste", was ich mal gesehen hab, war ein System namens myView. Das Frontend war praktisch komplett in einer absolut grausamen Templatesyntax, durchmischt mit HTML, umgesetzt. Hier wurde dabei allerdings so viel Programmlogik mit eingebaut, dass man es tatsächlich auch hart in Basic oder so hätte kodieren können, an Unübersichtlichkeit war das nicht mehr zu übertreffen.

Wenn schon Templates, dann wenigstens schlank und mit so wenig Logik aus der Anwendungsebene wie irgendwie möglich, darin sind wir uns wohl einig. Und ich finde, dass für die paar Sachen, die dann noch übrigbleiben, ein wenig PHP durchaus ausreicht, ohne unlesbar zu werden... da ist der Einsatz eines ressourcenfressenden Templateparsers imho wiederum der berühmte Schuss aus Kanonen auf Spatzen.

Ich habe bis vor kurzem selber Smarty benutzt (im CalitrixWiki ist es, leider, noch drinne). Ich halte mittlerweile weder von Templateengines wie Smarty noch von Plain-PHP-Templates etwas.

Was spricht gegen Smarty?
Man implementiert eine komplette Scriptsprache die in den meisten Fällen die gleiche Funktionalität wie PHP hat - lediglich in einer leicht unterschiedlichen Syntax. Der oft postulierte Vorteil - Designer müssten sich nicht mit PHP rumschlagen - ähnelt da einen Witz. Wo ist der große Komplexitätsunterschied zwischen {foreach from="$foo" item="blah"} ... {/foreach} und <?PHP foreach($foo as blah) {?> ... <?PHP } ?>? Kaum vorhanden, würde ich sagen ...
Ob man etwas wie Smarty oder Plain-PHP verwendet macht vom Aussehen und der Funktionsweise keinen besonders großen Unterschied.

Was spricht gegen PHP?
Für mich vorallem Sicherheitsaspekte. Wenn ich, wie im CalitrixWiki, multiple Themes unterstütze fangen Benutzer früher oder später an, eigene Themes zu erstellen und zum Download bereitzustellen. Ich für meinen Teil würde so ein Theme nicht bei mir einsetzen, schliesslich möchte ich nicht fremden PHP-Code auf meinem Webserver ausführen. Ich könnte zwar alle Templates nach böswilligem PHP-Code durchsuchen aber das ist mir a) zuviel Stress und b) keine Lösung für einen Benutzer der kein PHP kann.

Für eine kleine Anwendung die ich für meine eigene Website baue, ein Gästebuch zum Beispiel, sind PHP-Templates aber eine gute Lösung. Man hat keinen Stress und zusätzlichen Overhead durch eine Templateengine und da man sowieso nur selber an dem Layout bastelt kann man die Sicherheitsbedenken auch beiseite wischen.


Ein anderer Ansatz
Die Idee dazu ist mir gekommen als ich mich in meiner Firma in typo3 einarbeiten sollte. Dort gab es die möglichkeit einen HTML-Parser für Templates zu verwenden und die einzelnen (HTML)Bestandteile über ihre Tags und IDs anzusprechen.

Nehmen wir ein Beispiel: ich will eine Liste registrierter Benutzer anzeigen. Mit einer Engine wie Smarty geh ich folgendermaßen vor:

Ich frage mich jetzt: wozu der Umstand, wenn ich jeden Bestandteil der Tabelle auch über HTML-Tags und Element-IDs identifizieren kann? Erweitern wir einfach mal das Template:

In PHP könnte ich das Template jetzt einwandfrei ansprechen (nur als Beispiel):

Die Funktion Template::loopThrough(); würde jetzt hergehen, die Tabelle mit der ID "user-table" suchen, in der Tabelle nach einem <tr> suchen der <td>-Elemente mit class-Attribut enthält und die <tr> in einer Schleife durchlaufen und die Daten aus $data einsetzen.

Das Ganze ist jetzt nur beispielhaft und vielleicht noch nicht so richtig durchdacht. Mit der Methode kann man sich aber eine extra Templateengine inkl. extra Scriptingsyntax sparen: die Funktionalität um HTML nach Elementen zu durchsuchen ist mit PHP5, DOM und XPath bereits gegeben. Das ist auch für den Designer schön weil er sich nicht mit Templatescripting rumschlagen sondern lediglich sauberes HTML abliefern muss.

Eine Alternative wäre XML und XSLT, mit PHP5 ebenfalls ohne größere Probleme möglich.

Meine Meinung: Templateengines wie Smarty sind so nützlich wie Karies, es geht auch einfacher ...

Johannes, dein Ansatz hat einen entscheidenden Nachteil: Der Anwendungscode enthält Teile der HTML-Struktur. Was machst du jetzt, wenn ich mich entscheide, die Benutzer nicht in einer <table/>-Tabelle darzustellen, sondern mit <div/>s oder gar als <ul/>-Liste? Dann isses vorbei mit der Gestaltungsfreiheit. Die Grenze zwischen Anwendung und Template sollte weder vom Code, noch von der Darstellung abhängen. Oft hängen Templates vom Code ab, hier hängt mal der Code vom Template ab.

Ein anderer Anwendungsfall von Template-Scripting ist: Ich will mehrere Links anzeigen, alle mit einem Trennsymbol dazwischen, manche aber optional. Da sollen natürlich keine zwei Trennsymbole in Folge hin. Hier muss also im Template die Darstellung programmiert werden. Genauso könnte ich die Links ja auch als Liste oder alle ganz woanders darstellen, mit einem ordentlichen Templatesystem kein Problem. Hier wäre natürlich keine Behandlung der Trennsymbole notwendig.

Was spricht für mich persönlich gegen Smarty:
Mein eigenes System ist mindestens doppelt so schnell und die Codegröße ist weit weniger als die Hälfte (müsste nachschauen). Den Umfang von Smarty hab ich gar nicht komplett erfasst, das Ding kann jedenfalls viel zu viel für den Zweck für den es existieren sollte.