T-REx 2.2.0 TemplateEngine

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • T-REx 2.2.0 TemplateEngine

    T-REx 2.2.0 TemplateEngine

    Es ist soweit! T-REx 2.2.0 released.
    Nach einem Monat ist nun endlich die neue Version fertig.

    Track: syncom.org/svn/trex/
    Dokumentation: julian-stier.de/referenz.htm
    Download:
    Mirror Syncom:
    syncom.org/svn/trex/T-REx%202.2.0.zip | 22.9KB
    syncom.org/svn/trex/T-REx%202.2.0.ace | 19.9KB
    syncom.org/svn/trex/T-REx%202.2.0.tar | 90.0KB

    Mirror Julian-Stier.de:
    julian-stier.de/T-REx%202.2.0.zip | 22.9KB
    julian-stier.de/T-REx%202.2.0.ace | 19.9KB
    julian-stier.de/T-REx%202.2.0.tar | 90.0KB

    Ein bischen Geschichte..
    T-REx entstand, als ich in einem Projekt mit der TemplateEngine von phpBB konfrontiert wurde. Die Einfachheit dieser TemplateEngine war beeindruckend (zum Beispiel im Gegensatz zu smarty) und auch die Performance stand in Nichts nach. Jedoch war sie mir noch nicht flexibel genug und außerdem ist sie selbstverständlich geschützt. Daher entstand eine eigene TemplateEngine: T-REx 1.0. Aber schon bald war ich damit nicht zufrieden. Ich entdeckte viele Schwachstellen dieser phpBB-Methode. So entstand nach einigen Updates bereits eine beinahe grundsätzliche Umgestaltung der Funktionsweise und es entstand T-REx 2.0, deren besondere Eigenschaft es war, erst bei Aufruf der entsprechenden Methode zu kompilieren. Außerdem war es möglich Blöcke ineinander zu verschachteln. Nach und nach kamen wieder kleine Updates und schließlich kam, nach 2.1.2 der Wunsch die gesamte TemplateEngine nochmals neu (auf php5-Basis) und mit weit mehr Methoden zu schreiben. Das Ergebnis ist heute fertig geworden.


    Was ist T-REx, was ist eine TemplateEngine?
    Eine TemplateEngine dient dazu Dateien (Templates) zu verwalten und grundsätzlich nach Platzhaltern zu durchsuchen. TemplateEngines haben dabei sehr unterschiedliche Eigenschaften und verwalten grundsätzlich HTML-Dateien (bzw. Text).
    T-REx ist eine TemplateEngine, die zur Laufzeit "kompiliert". Sie kann dabei Platzhalter ("Variablen") und Textabschnitte ("Blöcke") ersetzen, mehrere Templates zusammenführen, Templates ineinander schachteln und einiges mehr. Im Gegensatz zu anderen TemplateEngines arbeitet T-REx ohne Cache, d.h. bei jedem Aufruf wird alles neu generiert (wie php auch selber stets von Neuem geparsed wird). Jedoch zeichnet sich die TemplateEngine dadurch aus, dass sie sehr kompakt gehalten ist und nur das Nötigste vornimmt. So folgt T-REx zwei Arbeitsschritten: Konfiguration, Kompilierung. Dadurch ist es möglich bereits während der Konfiguration abzubrechen (z.B. durch eine Weiterleitung, eine Bildausgabe), ohne dass eine Textausgabe vorgenommen wurde und ohne große Performanceverluste. Erst wenn ein Befehl zur Kompilierung kommt durchsucht die TemplateEngine die einzelnen Dateien und kompiliert alles.


    Was bringt T-REx besonderes mit sich?
    T-REx kann wie jede andere TemplateEngine auch Platzhalter verwenden. Im Gegensatz zu vielen anderen wird aber darauf geachtet zwischen Design und Code zu unterscheiden. Das Template hat nicht zu entscheiden, welcher Inhalt an einen Platzhalter kommen soll. Der Inhalt bildet ein drittes Medium (ausgelagerte Dateien, Datenbank, ..), der durch den Controller (Code) angesprochen wird. Nur der Code entscheidet, was mit einem Platzhalter geschieht. Viele TemplateEngines haben sogenannte Schleifen in ihren Templates, die es ermöglichen einen bestimmten Text oder ein bestimmtes Muster immer wieder zu wiederholen. Oft ist es aber so, dass dabei im Template festgelegt wird, wie oft oder auf welche Weise genau das geschehen soll. T-REx hat die möglichkeit Textabschnitte beliebig oft zu durchgehen, beliebige Platzhalter darin zu ersetzen und auch Textabschnitte innerhalb von Elternelementen zu durchgehen.
    Mit der neuen Version ermöglicht es T-REx außerdem eine eigene Fehlerbehandlungsfunktion oder eine eigene Kompilierungsfunktion (!) zu definieren. Somit kann man nicht nur HTML damit verarbeiten (oder wahlweise auch XML, ..), sondern auch mit geeigneten Schnittstellen PDF oder ähnliches.


    Sonstiges
    T-REx steht unter der GPL 3 und darf demnach von jedem erweitert, verändert und verbreitet werden, solange die Lizenz gleich und mein Name erhalten bleibt. Eine Dokumentation befindet sich noch im Aufbau und auch die Funktionsreferenz wird natürlich noch vervollständigt. Für Fragen steht meine eMail zu Verfügung: trex[at]julian-stier.de

    Kritik ist erwünscht, eine Diskussion, ob nun diese oder jene TemplateEngine besser ist nur unter der Vorraussetzung, dass jedem Teilnehmer der Diskussion bewusst ist, dass viele TemplateEngines ein anderes Konzept (das stets Vor- und Nachteile hat) verwenden und man diese Konzepte an sich, die TemplateEngines aber weniger vergleichen kann.



    lG



    php0Kid
    Julian Stier

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von PHP0Kid ()

  • Moin,
    zum Benutzen hatte ich jetzt noch keine Zeit, aber hier ein wenig Feedback unabhängig vom Code ;)
    Du hast sehr viel Code dokumentiert, das ist super (und selten). Aber die Kommentare solltest du in JavaDoc Syntax schreiben, so dass du auch mit doxygen ne anständige HTML Doku generieren kannst.

    Ansonsten ist die Engine natürlich einfacher... aber wenn du schon Smarty erwähnst, so fehlen mir einfach zu viele Sachen.

    Schleifen smarty.net/manual/en/language.function.foreach.php

    Quellcode

    1. <ul>
    2. {foreach from=$myArray item=foo}
    3. <li>{$foo}</li>
    4. {/foreach}
    5. </ul>


    Funktionen smarty.net/crashcourse.php

    Quellcode

    1. <select name=user>
    2. {html_options values=$id output=$names selected="5"}
    3. </select>


    Modifier

    Quellcode

    1. Name: {$name|capitalize}<br>


    Auch Smarty ist nicht perfekt. Eine gescheite Lösung zur Internationalisierung ist mir auch dort nicht gegeben...

  • Hi,

    danke für deine Antwort :)

    d0nut schrieb:

    Du hast sehr viel Code dokumentiert, das ist super (und selten). Aber die Kommentare solltest du in JavaDoc Syntax schreiben, so dass du auch mit doxygen ne anständige HTML Doku generieren kannst.

    wie sieht diese JavaDoc Syntax denn aus? Hättest du da einen Link für mich? :)

    d0nut schrieb:

    Ansonsten ist die Engine natürlich einfacher... aber wenn du schon Smarty erwähnst, so fehlen mir einfach zu viele Sachen.

    Jap, sie sollte vor allem handlicher, übersichtlicher und flexibler sein. Sie stellt auch ein anderes Prinzip als Smarty da.

    d0nut schrieb:

    Schleifen smarty.net/manual/en/language.function.foreach.php

    Quellcode

    1. <ul>
    2. {foreach from=$myArray item=foo}
    3. <li>{$foo}</li>
    4. {/foreach}
    5. </ul>

    Das sind meine so genannten "Blöcke". Smarty hat hier für mich persönlich die größte Schwäche: Es legt im Template fest, wie lang diese Schleife durchlaufen werden soll! Und zwar genau so lange, wie das Array $myArray Elemente hat. Bei mir wird das so umgesetzt:

    Quellcode

    1. {% ul %}<ul>
    2. {% li %}<li>{%li.foo%}</li>
    3. </ul>{% ul %}

    Das Ganze wird dann über php gesteuert (Controller und damit nicht Template!):

    Quellcode

    1. $ul = $template_instance->assign_block('ul');
    2. foreach($myArray as $var => $value){
    3. $ul_li = $template_instance->assign_block('li', $ul);
    4. $ul_li->assign_var('foo', $value);
    5. }

    Dabei kann man nun auch "ul" beliebig oft wiederholen :)

    d0nut schrieb:

    Funktionen smarty.net/crashcourse.php

    Quellcode

    1. <select name=user>
    2. {html_options values=$id output=$names selected="5"}
    3. </select>

    Ich verstehe leider nicht ganz, was das Beispiel großartig machen soll, daher kann ich kein Gegenbeispiel geben..

    d0nut schrieb:

    Modifier

    Quellcode

    1. Name: {$name|capitalize}<br>

    Modifier sind nicht schlecht, stimmt, aber damit greift auch wieder das Template auf Dinge zu, das so eigentlich nicht sein sollte. Kann man per php genauso lösen:

    Quellcode

    1. $template_instance->assign_var('name', capitalize($name));


    d0nut schrieb:

    Auch Smarty ist nicht perfekt. Eine gescheite Lösung zur Internationalisierung ist mir auch dort nicht gegeben...

    Mit Internationalisierung sprichst du "Multilingualität" an? So etwas sollte man meiner Meinung nach per Datenbank bzw. einem dritten Medium lösen: Inhalt. Ich finde Inhalt hat in Templates wenig zu suchen.. Grobe Umrandung (wie z.B. "Name: .. Adresse:") schon, aber mehr nicht. Dann wechselt man dazu einfach in ein anderen Templateordner ("MyStyle_english") und verwendet diese Templates. Zugleich nimmt man statt den deutschen die englischen Inhalte aus der Datenbank und schon hat man seine mehrsprachige Seite. Bischen kompliziert, aber was besseres weiß ich bisher auch noch nicht.

    Smarty hat glaube ich auch den Nachteil keine Mehrfachinstanzen zu besitzen. T-REx kann natürlich auf mehrere Templateordner zugreifen (und somit mehrere Styles etc haben).



    lG

  • Also doxygen kann mit ganz verschiedenen Kommentaren umgehen. Aber ich finde Javadoc ist ein weit verbreiteter Standard und mein Favorit: [wikipedia]Javadoc[/wikipedia]

    Was die Aufgabenverteilung zwischen Controller und View angeht, haben wir beide ganz unterschiedliche Auffassungen.

    Ich finde schon, dass die View Aufgaben wie z.B. Großschreibung, Textkürzung oder Entity-Umwandlung übernehmen sollte. Schließlich darf sich das zwischen unterschiedlichen Views unterscheiden. Der Controller soll die angefragten Daten wiedergeben, nicht aber aufbereiten.

    Bei der Schleife das selbe. Natürlich werden GET und POST Parameter vom Controller verarbeitet, um damit das Array, das die View bekommt, zu limitieren.
    Smarty verwendet einfach nur das Array und kümmert sich auf Ebene der View nur um die Darstellung dessen. Die View könnte also genausogut entscheiden einfach nur das allererste Element darzustellen.

    Bei deinem System schreibt der Controller schon die Verwendung in der Schleife vor.

    @Internationalisierung: Ja, Daten die der Controller liefert sollten schon fertig aufbereitet werden. Aber es kommen nicht alle Daten über den Controller. Ich meine Texte in den Templates. Smarty bietet schon Wege über Konstanten... ich akzeptiers auch als OK... aber hundertprozentig zufrieden bin ich nicht ;)

  • d0nut schrieb:

    Was die Aufgabenverteilung zwischen Controller und View angeht, haben wir beide ganz unterschiedliche Auffassungen.

    Ist leider immer so in diesem Bereich - da sind wir nicht die Ersten :D

    d0nut schrieb:

    Ich finde schon, dass die View Aufgaben wie z.B. Großschreibung, Textkürzung oder Entity-Umwandlung übernehmen sollte. Schließlich darf sich das zwischen unterschiedlichen Views unterscheiden. Der Controller soll die angefragten Daten wiedergeben, nicht aber aufbereiten.

    Du hast Recht, aber für mich ist das wieder ein Grenzfall: Klar, Großschreibung, Entity-Umwandlung etc ist eine klasse Sache, aber hier stellt sich mir die Frage wo man die Grenze dazu zieht und was die Seite machen soll. Ist es eine Website mit vielen verschiedenen Layouts (Designs) spricht nichts gegen meine Lösung, allerdings beinhalten sie beinahe den selben Inhalt.
    Großschreibung okay, auch Entityumwandlung ist noch okay, aber ab einem bestimmten Punkt nimmt für mich die Formatierung CSS vor und nicht mehr xHTML. Daher braucht man das eigentlich gar nicht :)

    d0nut schrieb:

    Bei der Schleife das selbe. Natürlich werden GET und POST Parameter vom Controller verarbeitet, um damit das Array, das die View bekommt, zu limitieren.
    Smarty verwendet einfach nur das Array und kümmert sich auf Ebene der View nur um die Darstellung dessen. Die View könnte also genausogut entscheiden einfach nur das allererste Element darzustellen.

    Bei deinem System schreibt der Controller schon die Verwendung in der Schleife vor.

    Das verstehe ich nicht ganz - was schreibt mein Controller vor? Ich könnte genausogut eine for-Schleife verwenden, oder die Ergebnisse aus einer Datenbank verwenden.. Für mich ist bei Smarty vorgeschrieben, dass diese und jene Variable verwendet werden -muss-. So kann ich immer noch im jeweiligen Template einfach den Block weglassen und schon erscheint die jeweilige Passage nicht.

    d0nut schrieb:

    @Internationalisierung: Ja, Daten die der Controller liefert sollten schon fertig aufbereitet werden. Aber es kommen nicht alle Daten über den Controller. Ich meine Texte in den Templates. Smarty bietet schon Wege über Konstanten... ich akzeptiers auch als OK... aber hundertprozentig zufrieden bin ich nicht ;)

    Konstanten in Smarty? Wie unterscheiden die sich von Variablen und was bezwecken sie?


    lG

  • PHP0Kid schrieb:

    Ich könnte genausogut eine for-Schleife verwenden, oder die Ergebnisse aus einer Datenbank verwenden..

    Dann hättest du aber Änderungen in PHP und TPL Code, oder?
    Smarty ist hier einfach wesentlich komfortabler. Bei Smarty machst du nur eine einzige Zuweisung auf ein Objekt über das man iterieren kann.
    Ob man das dann in einer Schleife nutzt oder nicht entscheidet der Template Code. Auch welche Spalten du anzeigen möchtest schreibt Smarty nicht vor.

    PHP0Kid schrieb:

    Konstanten in Smarty? Wie unterscheiden die sich von Variablen und was bezwecken sie?

    Naja, mit der Internationalisierung gehen wir vom Thema weg ;)
    Es gibt conf-Dateien die man Laden kann. Ähnlich den Properties Dateien bei Java Enterprise. Allerdings bin ich mir nicht sicher, ob man hier über mehrere Dateien arbeiten kann.

    Ich bin eigentlich gar kein Smarty Verfechter... vor allem wenn man modular programmiert wirds schwierig. (Wie du ja erwähnt hast.. mehrere Ordner = schlecht)
    Aber ich hab mich noch nie "richtig" mit Smarty befasst. Bestimmt gibts irgendwo "best practices" dazu.

  • d0nut schrieb:

    PHP0Kid schrieb:

    Ich könnte genausogut eine for-Schleife verwenden, oder die Ergebnisse aus einer Datenbank verwenden..

    Dann hättest du aber Änderungen in PHP und TPL Code, oder?
    Smarty ist hier einfach wesentlich komfortabler. Bei Smarty machst du nur eine einzige Zuweisung auf ein Objekt über das man iterieren kann.
    Ob man das dann in einer Schleife nutzt oder nicht entscheidet der Template Code. Auch welche Spalten du anzeigen möchtest schreibt Smarty nicht vor.


    Gerade DAS macht meine TemplateEngine wesentlich einfacher :) :

    Quellcode

    1. {% news %}<h1>{%news.title%}</h1>
    2. <p>{%news.content%}</p>
    3. <p id="footer">by {%news.author%}, {%news.date%}</p>
    4. {% comments %}<h2>{%comments.title%}</h2>
    5. <p>{%comment.content%}</p>
    6. <p id="footer">by {%comments.author%}, {%comments.date%}</p>{% comments%}
    7. {% news %}


    Joa, das ist mal ein einfaches Beispiel. Damit kann man schon ne Menge in Sachen "Newsseite" machen:
    Fall a) Es existieren keine News / der News-Block im Template existiert nicht
    -> das Template wird ohne den oben genannten Code geparsed
    Fall b) Es existieren News / Parameter für Kommentare nicht gegeben
    -> News werden ausgegeben, den inneren Block mit den Kommentaren sieht man nicht (bzw existiert auch nicht)
    Fall c) Es existieren News und Parameter für Kommentare ist gegeben (Controller sucht auch nach Kommentaren)
    -> News werden ausgegeben und zu jeder News auch beliebig viele Kommentare

    Einen Block kann man beliebig oft (0 - x) verwenden, genauso wie Blöcke innerhalb von ihm. In was für einer Schleife, oder ob er einfach so verwendet wird, ist egal. Man kann also zum Beispiel auch ein Controller machen, der für einen Weblog die 3 neuesten Einträge sucht und für News die 5 neuesten Einträge. Nun gibt es vier Styles: Das eine hat nur einen Newsblock und gibt damit die aktuellsten fünf News aus. Der zweite Style hat nur einen BlogBlock und gibt die 3 aktuellsten Blogeinträge aus. Ein weiterer Style hat sowohl Blog- als auch Newsblock und gibt beide an den jeweiligen Stellen aus. Der vierte Style hat keine Übersicht über die neuesten News oder Blogeinträge und gibt somit keine Blockeinträge aus :)

    Ich sehe da weit aus mehr Flexibilität. Man kann mit diesen Textabsätzen -alles- machen, was ich mir vorstellen kann im Moment.. wüsste kein Beispiel, was nicht möglich ist.


    lG

  • PHP0Kid schrieb:

    Gerade DAS macht meine TemplateEngine wesentlich einfacher

    Smarty hat aber auch "sections". Ich will nicht sagen, dass das, was abgebildet wird (Iteratoren fehlen glaub ich) in deiner Engine wesentlich komplizierter ist. Aber im PHP Code ist es (für mich) komplizierter.

    Aber schließen wir das ab.. Wir kommen bei der Diskussion nicht auf einen gemeinsamen Nenner ;)

  • Dein Projekt in allen Ehren, kann nur einige Sachen nicht nachvollziehen:

    1.)
    Die Einfachheit dieser TemplateEngine war beeindruckend (zum Beispiel im Gegensatz zu smarty)

    Also ich weiß nicht, was man gegen die "Einfachkeit" in Smarty sagen kann:

    Quellcode

    1. Inhalt: {$content}

    Was ist daran bitte kompliziert? Ausser, dass man vielleicht noch nen template- und nen cache-Ordner definieren muss.


    2.)
    In Bezug auf 1.) versteh ich nicht, warum ich ne Tabelle noch mal mit Engine Tags vertzieren soll, wie im Beispiel include.tpl

    Quellcode

    1. <h2>Include.tpl</h2>
    2. Ein includeter Inhalt!
    3. {% table %}<table style="border: 1px solid black;">
    4. {% tr %}<tr>
    5. {% td %}<td>{%td.content%}</td>{% td %}
    6. </tr>{% tr %}
    7. </table>{% table %}



    3.)
    T-REx ist eine TemplateEngine, die zur Laufzeit "kompiliert".

    Das ist doch schon mal Käse... Das wird bei kleineren Seiten vielleicht funktionieren, aber je eher der Traffic ansteigt, desto schwerwiegender sind die Performanceverluste, die daraus resultieren, das Template zu laden, zu parsen, auszugeben. Das bei der Konfiguration abgebrochen werden kann ist schön und gut, aber wohl eher der Ausnahmefall - Im Normalfall wird das Template geladen (IO), geparsed (CPU) und ausgegeben.


    4.)
    Auch Smarty ist nicht perfekt. Eine gescheite Lösung zur Internationalisierung ist mir auch dort nicht gegeben...


    Auch hier gibts eine Lösung: SmartyML, ob das vorgehen mit einer Datei, gut ist oder nicht, lässt sich streiten. Es ist zwar keine offizielle Lösung, aber Sie funktioniert tadelos.

  • Hi und danke für deine Kritik :)

    BennyBunny schrieb:

    1.)
    Die Einfachheit dieser TemplateEngine war beeindruckend (zum Beispiel im Gegensatz zu smarty)

    Also ich weiß nicht, was man gegen die "Einfachkeit" in Smarty sagen kann:

    Quellcode

    1. Inhalt: {$content}

    Was ist daran bitte kompliziert? Ausser, dass man vielleicht noch nen template- und nen cache-Ordner definieren muss.

    Es geht nicht um die Oberfläche :) T-REx hat genauso wie die TE von phpBB den Vorteil klein zu sein. Ich habe bei meinen Tests gemerkt, dass allein schon das Einbinden der Datei viel an Performance ausmacht. T-REx zu instanzieren ist lange nicht so "schlimm" wie smarty ;)


    BennyBunny schrieb:

    2.)
    In Bezug auf 1.) versteh ich nicht, warum ich ne Tabelle noch mal mit Engine Tags vertzieren soll, wie im Beispiel include.tpl

    Quellcode

    1. <h2>Include.tpl</h2>
    2. Ein includeter Inhalt!
    3. {% table %}<table style="border: 1px solid black;">
    4. {% tr %}<tr>
    5. {% td %}<td>{%td.content%}</td>{% td %}
    6. </tr>{% tr %}
    7. </table>{% table %}

    Nunja, jede TemplateEngine hat natürlich so seine "Platzhalter" oder wie man es auch nennen mag. Diese "EngineTags", wie du sie nennst dienen dazu, dass die TE erkennt, wo ein Block beginnt und endet. Sie sind dazu da den darin enthaltenen Inhalt beliebig oft wiederzugeben (ich hoffe Mal, du hast die obige Diskussion etwas verfolgt ;)). Mit diesem Beispiel kann man beliebig oft eine Tabelle in allen beliebigen Styles untereinandersetzen. (Ich verwende einen ähnlichen Code bei einer Seite, bei der man z.B. Nachrichten angezeigt bekommt)


    BennyBunny schrieb:

    3.)
    T-REx ist eine TemplateEngine, die zur Laufzeit "kompiliert".

    Das ist doch schon mal Käse... Das wird bei kleineren Seiten vielleicht funktionieren, aber je eher der Traffic ansteigt, desto schwerwiegender sind die Performanceverluste, die daraus resultieren, das Template zu laden, zu parsen, auszugeben. Das bei der Konfiguration abgebrochen werden kann ist schön und gut, aber wohl eher der Ausnahmefall - Im Normalfall wird das Template geladen (IO), geparsed (CPU) und ausgegeben.

    Das ist wie bereits gesagt Geschmacks- bzw. Ansichtssache. Der Nachteil ist natürlich stärkere Performanceverluste. Ich werde aber, sobald ich Zeit finde, Beispiele erstellen (mit längeren Codezeilen, MySQL-Anfragen, ..) bei denen einmal phpBB´s Engine, smarty und einmal T-REx verwendet wird um die Stärken der einzelnen Systeme zu zeigen.
    Ich würde phpBB nicht als kleines Projekt bezeichnen, aber es ist wirklich eine persönliche Sache, wie man es lieber hat. Theoretisch ist es auch möglich mit T-REx ein Cache zu verwenden :) Man kann eine eigene Komplierungsfunktion bauen. Dann kann man zum Beispiel ein Delay von 2min für größere Seiten einbauen, in denen eine Cache-Datei geladen wird. Ist natürlich nicht mit Smarty vergleichbar, da smarty die Templates wiederum in php umwandelt.


    BennyBunny schrieb:

    4.)
    Auch Smarty ist nicht perfekt. Eine gescheite Lösung zur Internationalisierung ist mir auch dort nicht gegeben...


    Auch hier gibts eine Lösung: SmartyML, ob das vorgehen mit einer Datei, gut ist oder nicht, lässt sich streiten. Es ist zwar keine offizielle Lösung, aber Sie funktioniert tadelos.

    Dazu kann ich wenig sagen, weil ich mich nur wenig darin auskenne. Smarty ist eine Bibliothek einer Größe, mit der ich mich eigentlich nur ungern vergleichen will :)
    Wenn man sich aber umschaut, wird man viel Kritik gegenüber Smarty finden, genauso wie man viel Kritik an T-REx anbringen kann. Das ist einfach ein Gebiet, das sehr streitfällig ist!


    lG