Tidbits Template Class (habe ich selbst gemacht!)

Mich würden mal Performance-Messungen interessieren zu deiner Template-Klasse. Ich bin für das BlackBoard noch auf der Suche nach einer Template-Klasse, hab's damit aber nicht eilig.

Außerdem hab ich ein paar kleinere mögliche Problemfälle in dem Skript gefunden:
* Das Entfernen der PHP-Teile könnte den PHP-Code zerstören, weil beim preg_replace() die ' und " im \1 teilweise ge-\-t werden.
* Den foreach-Code hab ich jetzt auf Anhieb nicht kapiert, aber bei if/else bin ich mir ziemlich sicher, dass man die nicht verschachteln kann. Erweiterte if/else/else... (als switch-Ersatz) wären dann nicht möglich. Weiß nicht, inwieweit das notwenig werden könnte.

Die Klasse funktioniert nur ab PHP 4.3+, mindestens wegen dem file_get_contents(), das ist mir gleich aufgefallen. Ein join('', file()) schafft da Abhilfe. Ansonsten müsste der Code auch ab PHP 4.1 oder sogar früher laufen.

Der Code ist schön kompakt und scheint doch die Grundlegenden Template-Funktionen bereitzustellen (hab's noch nicht getestet). Wenig Code -> schnelleres Einlesen.

Hi.

Nett, nur für mich leider 1 Woche zu spät, bin gerade dabei meine Templates mit meinem System einzubauen

Wegen dem file_put_contents() verweise ich hierdrauf: http://www.webstyleboard.de/wsb/thre...?threadid=4823 alternativ können Funktionen von PEAR::Compat benutzt werden.

MfG MaMo

Danke für eure Bewertungen, ich werde in den nächsten Tagen das mit dem file_get_contents ausbessern und die Möglichkeit hinzufügen, else ifs einzufügen.

@LonelyPixel: An die Sache mit den PHP-Sektionen hatte ich auch erst gedacht, aber da die ge-\-ten Argumente vom Template-Parser in PHP-Strings geschrieben werden, stellt das kein Problem dar, denn wenn die Strings noch nicht in diesem Format wären, dann müssten sie sowies umgewandelt werden, um keinen Parse-Error zu erzeugen. Ich denke aber darüber nach, das ersetzen der PHP-Sektionen nicht mehr mit str_replace, sondern einfach als <?='<? PHP-Code';?> zu machen, das ist sicher performanter.

Die Template-Klasse ist sicherlich sehr schnell, wenn reuse_code auf True gesetzt wird, weil das Template als PHP-Code ausgeführt wird und Variablen nicht per Funktion, sondern per Array zugewiesen werden. Dann muss das Template nur ien einziges Mal in PHP-Code umgewandelt werden und wird von dort an nur noch als PHP-Code ausgeführt, ohne reguläre Ausdrücke! Trotzdem wäre ein solcher Performance-Test sicher recht interessant, hat jemand iene Ahnung, wie man sowas machen könnte?

Hm, hab sowas noch nicht gemacht, aber mit microtime() bekommst du ne sehr genaue Zeitmessung und dann müsstest du einfach nur die Ausführungszeit (compile + run from cache) mit verschiedenen Systemem messen. Mit einer vergleichbaren Template-Seite natürlich.

Update auf Version 1.02!

Arbeite übrigens zurzeit an einem Persormance-Test!

Gibt's schon Neues zu dem Test? Ich würd in den nächsten Monaten eventuell schon anfangen, eine Template Engine zu verbauen...

Achso!

Ja, ich habe das Skript inzwischen für meine Galerie-Software weiterentwickelt.

Ich habe schonmal die Dokumentation für die aktuelle Version gepostet, das Skript kann ich in den nächsten Tagen nachliefern.

Bei meiner Galerie-Software habe ich auf Seiten, die nur ein Template enthalten, bisher die Erfahrung gemacht, dass selbst wenn man die Templates nicht zwischenspeichert, die Ausführungzeiten recht kurz sind. Sie steigen allerdings enorm, wenn mann sehr viele Templates ohne Pause hintereinander parst, was in der Praxis allerdings nie vorkommen wird, weil man sich durch Includes ein entsprechendes Template zusammenbasteln kann, sodass man nur eins pro Seite benötigt.

Einen kleinen Test habe ich bereits unternommen, das Ergebnis lässt sich unter
http://www.draconum.de/files/tidbits_template_test.html (ca 900 KB)
abrufen.

Wenn Interesse besteht, kann ich in den nächsten Tagen mal eine allgemein einsatzbare Datei für v1.03 zusammenstellen, denn bis meine Galerie-Software einsetzbar sein wird, kann es noch dauern.

Ich als Unwissender wollte mal fragen, ob das bisschen Code was du im ersten posting geschrieben hast wirklich alles ist. An welcher Stelle werden denn da beispielsweise die if ( ) und foreach Sachen umgewandelt?

@archibald:

Die IF-Abfragen werden durch einen Funktionsaufruf umgewandelt
Die oben gepostete Version sollte allerding snoch nicht produktiv eingesetzt werden, weil sie noch einige offensichtliche Fehler enthält. Zum Beispiel kann man in Stings innerhalb von IF-Abfragen keine Leerzeichen verwenden. Inzwischen arbeite ich an einer aktualisierten Version. Die nächsten Tage werde ich diese veröffentlich.

Schau einfach im Changelog des Skripts bei v.103 nach, dort findest du die entsprechenden Neuerungen. Ich plane auch, die Variablen in Zukunft durch ein "$"-Zeichen zu kennzeichnen, um den Zugriff auf Konstanten zu ermöglichen. Außerdem ist ein "Phrase"-modul geplant, um die Verwendung von mehrsprachigen Templates zu unterstüzen. Des weiteren ist auch noch eine "eval"-Funktion geplant, um Variablen als Template-Code parsen zu können.

EDIT:

Das würde bedeuten, dass Variablen von nun an in folgender Schreibweise notiert werden würden:

$variablenname (= variablenname)
oder
$variablenname.schlüssel (= variablenname['schlüssel'])

Ein weiteres Ziel ist, Erweiterungen (Funktionen) auch für Variablen innerhalbvon Funktionen benutzen zu können:

Hierfür gäbe es folgende Möglichkeiten:

erweiterung($variablenname)
oder
variablenname.erweiterung([paramter1[, parameter2]])

Wobei ich eher mit der zweiten Variante liebäugle. Welche würdet ihr bevorzugen?

Ein weiteres Problem beim Template-Caching ist, dass in Version 1.03 zwar das Haupttemplate jedes Mal neu geparst wird, wenn die Template-Datei geändert wurde, allerdings nicht die Includes, falls nur deren Dateien geändert wurden, daher werde ich in Zukunft wohl darauf setzen, dass auch diese überprüft werden.

"Phrase-Modul:"

Einfacher Ausruck:
{$phrase.phrasename}

Ausdruck mit Parametern:
{phrase[ 1="wert1"[, 2="wert2"]]}phrasename{/phrase}


Ihr seht also: es lohnt sich, noch ein wenig zu warten. In den Weihnachtsferien sollte das zu schaffen sein.

An dieser Stelle habt irh auch noch die Möglichkeit, weitere Wünsche zu äußern odr mir zu sagen, was ihr an "Tidbits Template Engine" für Quatch haltet!

Hier sind meine Anmerkungen dazu:

* Schreib doch bitte ein Datum zu den Versionen ins Changelog mit rein.

* Ich fände eine XML-Syntax wie <if cond="...">...</if> interessant. Ich glaub das vB verwendet diese Schreibweise, hab sie jedenfalls mal irgendwo gesehen. Dann könnte man auch gleich HTML-Kommentare rauswerfen (aufpasse auf die IE conditional comment hacks, vgl. IE7). Meinungen?

* ALTROW bei foreach würde ich genau andersrum definieren, dann stimmt es mit der modulo-Operation überein. Also 0 für gerade und 1 für ungerade. Und das ROW_ID/ROW_NUM finde ich etwas verwirrend. IMO war die vorherige Lösung OK, und wer bei Null anfangen will, kann ja eins abziehen.

* Die Syntax der foreach-Schleifen hab ich nicht verstanden. Wie kann ich da auf das jeweils aktuelle Element zugreifen? Z.B. bei {foreach users} mit users = array(name, id, location), wie kann ich diese drei Werte in der Schleife verwenden? Einfach nur mit {name}? Dazu müssten Variablen in foreach-Schleifen ja anders interpretiert werden als woanders. Und die Verschachtelung wird sicher eine ziemliche komplexe Sache... Wenn man da wie in PHP einfach Namen für die Laufvariablen geben könnte, wär es sicherlich einfacher.

* Du solltest deine UND/ODER/XOR Operatoren nach logisch (&&) und bitweise (&) trennen.

Ansonsten werd ich mir den Code dann demnächst mal anschauen, wie einfach ich ihn bei mir verbauen kann und wie es bei mir mit der Performance aussieht.

@LonelyPixel: Gute Argumente, werd emir das ganze Mal zu Herzen nehmen, besonders mit den Bit-Operatoren hatte ich das sowieso vor, weil meine Galerie-Software Bitfelder für Berechtigungen benutzen wird und dafür braucht man nunmal Bit-Operatoren, wenn das Ganze teilweise Template-Gesteuert werden soll.

Eine komplette XML-Syntax wäre natürlich eine überlegung wert, wobei ich noch nicht wüsste, wie ich es dann mit den Variablen machen sollte.

Entweder irgendwas von dem
<var name="variablenname" />
<var>name</var>
<var name="variablenname" function="funktion" 1="argument1" />

oder:
{$variable}
{$variable.funktion()}

mir geällt bei einer XML-Syntax nur nicht, dass ich nicht einfach
<if $a==b>[...]<else />[...]</if>
schreiben kann, sondern in dem fall
<if cond="$a == $b">[...]<else />[...]</if>
schreiben müsste. Wobei das bei IFs und FOREACHs noch zu ertragen wäre, ich hätte nur keine Lust, jedes Mal bei einer Variable <var name="varname" /> zu schreiben, daher werde ich für die Variablen wohl auch weiterhin die geschweiften Klammern verwenden. Man Könnte diese natürlich auch optional ohne die Klammern schreiben. Auch werde ich bei den Variablen bei der Objekt-Schreibweise bleiben. Denn diese ist ein wichtiger Bestandteil der Template-Engine und ist in diesem Falle für mich überzeugender, als die PHP-Schreibweise für Arrays, denn nur mit dem objektorientierten Ansatz kann man so schöne Sachen wie $parent.varname machen.
Das Dollarzeichen ist notwendig, um Variablen von Konstanten unterscheiden zu können.

Aber erstmal folgende Lösungen für Strukturen:
<foreach var="$varname"></foreach>
<if cond=""></if>
<if cond=""><elseif cond="" /><else /></if>
<include file="$string">

Sprachvariablen:
{$phrase.name} (Sprachvariablen ohne Parameter)
<phrase 1="$arg1" 2="arg2">{$phrase.name}</phrase>
Diese schreibweise ermöglicht das Einbinden von Variablen in die Sprachvariablen,
wenn ein Argument nicht von einem "$"-Zeichen angeführt wird, dann wird es als Wert, statt als Variable betrachtet, damit schließt man allerdings aus, dass Konstanten in Sprachvariablen verwendet werden können, dass sollte meiner Meinung nach aber nicht allzu schlimm sein!

Normale Variablen:
{$variable}
{$variable.htmlspecialchars()}

Was haltet ihr von der Syntax?

Zu der Lokalisierungssache kann ich nicht viel sagen, da ich mir die wahrscheinlich weiterhin in der Anwendung zusammensetzen werde. Dafür ist die Logik stellenweise zu komplex. Und wenn, bei mir ist das nur ein Text-keyed Array, und wenn überhaupt, kann man dafür sonst nur eine normale Funktion einsetzen. Was muss eine Template Engine hierbei besonderes können?

Aber zur XML-Syntax: Wenn, dann hieße es <include file="..." />, da es hier kein schließendes Tag gibt.

Das mit den Variablen ist natürlich zu lang. Hier wäre evtl. ein Mischbetrieb sinnvoll. Wobei eine fully bloated XML-Syntax natürlich immer mehr Schreibarbeit bedeutet, da hast du auch recht. Also vielleicht doch nicht so gut?

Für Funktionsaufrufe: Warum machst du nicht einfach {funktion var1 var2 "var3"}? (Berechnungen kommen dann in Klammern.) Dass funktion eine Funktion ist, lässt sich rausfinden, und Variablen mit gleichem Namen kann es nicht geben. (Das sag ich jetzt mal so...) Damit wäre die Sachlage eindeutig. Wozu brauchst du eigentlich Konstanten? Willst du da Textschnipsel mit Inhalten füllen oder ne halbe Programmiersprache mitsamt aller mehr oder weniger sinnvollen Sprachelemente nachbilden? Halte es so einfach wie möglich und code nur das nötigste, um alle erforderlichen Funktionen durchzuführen. Das macht es schneller, kleiner und besser wartbar.

Ja, OK, so furchtbar genial ist die Bitmasken-Idee nun auch nicht. Ich würd ihren Ursprung mal so grob in die 70er Jahre schieben. Ich verwende sie ja auch teilweise. Aber trotzdem wär ich irgendwie dafür, Variablen ohne das $-Zeichen zu beschreiben. Da mehr Variablen vorkommen, sollte das vereinfacht werden. Kannst du nicht ein %-Zeichen (oder eins, das noch frei ist, # z.B.) vor Konstanten setzen, oder was in der Richtung?

Klar, das wär auch ne Idee, wenn man das Machen wollte, dann müsste man aber ein Zeichen nehmen, dass bisher noch nicht in den Formal vorkommt und trotzdem passend ist, daher fällt das "%"-Zeichen schonmal raus. Als Favoriten bleiben bei mir dann
"#", "§", "$" oder "?" übrig. Man kannes natürlich auch als frei definierbar wählen.

Mir gefiel halt das $-Zeichen vor Variablen, weil es der PHP-Schreibweise ähnelt und somit für die Leute, die das Skript einsetzen werden, keine umgewöhnung ist. Bin mir aber selbst noch nicht so ganz sicher, wie ich das nun machen werde...

Templates sind ja dafür da, dass grade nicht-PHP-Programmierer das Aussehen einer Oberfläche verändern können. Wir sollten also mal nicht zu viel PHP/Perl-Wissen voraussetzen. Das $ könnte auch daher so manchem seltsam anmuten. Ich kenn mich jetzt aber mit anderen Template Lösungen nicht so aus, vielleicht ist das ja doch Standard so?

Mit dem §-Zeichen weiß ich net so recht. Das hat bei mir mal Probleme mit verschiedenen Codierungen verursacht, wohl weil es im Extended ASCII Bereich liegt. Und es sieht nach Gesetzen aus...

Hallo zusammen,
dies ist mein erster Beitrag hier. Ich bin ebenfalls über diesen link hier hineingestolpert, da ich mich auf einem Google-Kreuzzug nach Algorithmen, die sich zum Parsen von Dokumenten/Baumstrukturen bewährt haben, befinde.

Wie auch immer, interessehalber habe ich mich durch diesen und den älteren Thread mal gehangelt und auch das Script einmal ausprobiert (die Syntax – ebenfalls wie die von Smarty – finde ich wohl grauenhaft ... ist wohl Geschmackssache). Viel gravierender fand ich, dass folgender Codeschnippsel im Template:
mit folgenden Variablen gefüttert:
Folgende Ausgabe produziert:

Versuche doch als Tipp einfach mal, nicht jedes Einzelelement zu regexen, das wird bei komplexen Strukturen ja der blanke Horror. Splitte vielmehr die Blockelemente allgemein, indem du nach Open-Tags, Close-Tags und dem "Rest" (meinethalben CDATA) suchst und diese einfach auch nen Stack wirfst.

Willst du – wie vorgeschlagen – auf eine Art XSL-Syntax umsteigen (finde ich auch ganz hübsch), so kannst du ja sogar den eingebauten PHP-XML Parser verwenden, um deinen kompletten Baum in ein Array zu werfen, welches du dann nur noch auswerten musst. Du kannst deine "Spezialelemente" ja dann mit einem Namespace versehen:
o.Ä.

Viel Spaß beim Knobeln!!!!

Du suchst Parser-Algos? Schau doch mal bei meinem Advanced BBCode vorbei. Das ist eine (leider recht veraltete) Version dessen, was ich in meinem Board verbaut hab, um BBCode-Tags (bislang) fehlerfrei zu erkennen.

Was mich auf die Idee bringt, dass ich ja eigentlich auch meine eigene optimierte Parser-Engine für Templates hernehmen könnte... Templates für ein Forum in BBCode verfasst... Das hätte doch was?

Und die Sache mit dem XML von PHP: 1. würde das IIRC PHP5 erfordern, und 2. noch dazu eine grammatikalisch korrekte Vorlage des Template-Authors, richtig? Das wird dann doch etwas fehleranfällig. (Andererseits ist eine korrekte XML-Syntax sowieso erstrebenswert, wenn nicht gar erforderlich.)

direkt eine Antwort
Richtig, ich bin davon auch wieder abgekommen, aber aus einem anderen Grund: Viel zu viel Tipparbeit (ich verwende bspw. meist auch lieber schnell mal'n Perlscript, als ein XSL-Sheet, da schreibt man sich ja die Finger wund...). Die XPat-Funktionen (SAX-Parser) sind ja auch bereits in der PHP 4 Distribution vorhanden. Dass die Quelle wohlgeformt sein muss sehe ich auch eher als Vorteil, ist aber vor allem Geschmacks- und Gewöhnungssache.

Ich habe für meinen eigenen Templateparser immerhin erst einmal das (abgeleitete) Prinzip des von PHP bereitgestellten XML-Array geklaut (das, was die Methode xml_parse_into_struct() zurückliefert). Aber vielleicht finde ich hinter deinem Link ja noch Besseres? Danke jedenfalls!!!

So, hier ist mal ein neuer Anfang, die Dokumentation ist leider noch sehr schlecht und es stecken wahrscheinlich noch sehr viele Fehler drin, aber schaut es euch einfach mal an und sagt, was ihr davon haltet!

Angehängte Dateien

TidbitsTemplates_11alpha.zip (11,0 KB, 107x aufgerufen)

Hm, die XML-Schreibweise hat irgendwie noch einen kleinen Nachteil, fällt mir grade auf: Es sieht hässlich aus, wenn man Bedingungen oder Funktionen innerhalb von HTML-Elementen verwenden will.

@LonelyPixel: Das stimmt natürlich, das Problem lässt sich allerdings lösen, indem man einfach die Funktion "iif" (wird in template.php definiert) erlaubt und diese mit den entsprechenden Parametern in geschwungene Klammern schreibt:
<a href="test.php"{iif(setting.opennew, ' target="_blank"')}>

Damit wirft du zwar immer noch die XML-Kopatiblität über Board, aber diese ist in Templates sowieso letztendlich nichts als reine Illusion.
Die Funktion "iif" werde ich in der nächsten Version von vornherein erlauben. Ein letztes Problem bleibt allerdings bei Phrasen innerhalb von HTML-Elementen, dort muss man nach wie vor HTML in HTML-Elementen schreiben oder
"tt_construct_phrase" mit dem Alias "phrase" erlauben und folgendes schreiben:
<img src="" alt="{phrase(pharse.imgalt, filename, 'param2' [,...])}" />

Wie gesagt, TT ist da sehr variabel!
Wie ist sonst euer Eindruck von der überarbeiteten Version?

PS: Die Klassen habe ich weggelassen, weil es manchmal sehr nervig sein kann, wenn man mal mehrere Templates innerhalb einer Datei braucht und man jedes Mal eine neue Klasse erstellen muss, in der dann letztendlich nur eine Funktion aufgerufen wird, bis sie wieder Geschichte ist! Daher habe ich mich jetzt für eine non-OOP-Lösung entschieden, das AFAIK schneller und IHMO praktischer ist.

Weiß nicht... kommt mir immer noch ein wenig unausgegoren vor, v.A. die riesigen RexExprs... das ganze scheint mir nicht so sehr flexibel zu sein in der Hinsicht, neue Funktionen einzufügen.

Was machst du bspw., wenn du Schleifen implementierst? Dann musst du doch sowieso (Beispiel: <while condition="[..]"> [...] </while>) den mittleren Anweisungsblock wiederholen, ohne, dass du u.U. im Vorfeld die Stop-Bedingung kennst. Hier kommst du ohne Rekursionen gar nicht aus...