Template Engines - Anderes Prinzip

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

  • Template Engines - Anderes Prinzip

    Hi,
    ich habe nun schon länger vor mir ne kleine Template Engine zu schreiben, smarty sagt mir irgendwie nicht richtig zu.

    Nun gibt es ja immer die bestimmten Template Auszeichnungssprachen, die ja irgendwie auch Teile der Logik ersetzen,
    ich würde aber gerne einen anderen Ansatz wählen.

    Die Templates sollen reines HTML enthalten, ausgenommen der Platzhalter (z.B. in Form: {content} )
    Grafiken sollen auch vom Benutzer einfach so eingebaut werden können, damit man WYSIWYG support hat, das heißt er braucht nicht den richtigen Image Pfad eingeben (von der Indexdatei müsste das ja sonst sein).
    Also wenn er im Template ordner dann einen unterordner "gfx" hat müsste das Script daraus z.B. "templates/gfx/" machen.

    Da stößt man natürlich auf einige Probleme.

    • Wie soll man Schleifen abarbeiten ?
      • Ein Ansatz wäre es in dem Fall dann das Template File in jedem durchlauf neu zu laden, die Platzhalter zu ersetzen und auszugeben.

        Quellcode

        1. while(1==1) {
        2. #template einlesen;
        3. #repace;
        4. #ausgabe;
        5. }
    • Was ist mit leeren Tags, die gelöscht werden sollen ?
      • z.B. gibt jemand in nem Gästebuch-Eintrag keine ICQ Nummer ein, wie soll man dann das Feld für die ICQ Nummer rauslöschen ? Man weiß ja auf PHP Seite nicht, wie viele Tags jetzt für dieses Feld gebraucht werden (z.B. nur ein DIV oder aber mehrere Tabellenelemente)
    Mehr Probleme fallen mir jetzt spontan nicht ein, reicht meiner Meinung nach aber auch.

    Was ich nun möchte ist eure Meinung ;)

    (Und natürlich möchte ich ein frohes Fest wünschen :) )
  • überleg dir das gut, dich von etablierten Standards abzuwenden. OpenSource funktioniert dank Standards. Nicht nur dass Smarty schon lange existiert und tausendfach getestet ist, außerdem gibt es tausende Programmierer, die Smarty bereits kennen und sich ohne Einarbeitung in dein Projekt einbringen können.

    Zur Problematik.
    Lad doch in einem Rutsch alle Template-Platzhalter in ein Array und ersetze sie so.
    preg_match_all("/{\w+}/siU", $file, $regex);

    oder mit preg_replace und dem e-modifier
    Dann könntest du innerhalb der Funktion einen statischen Counter hochzählen lassen und so die Ersetzungen realisieren.
  • Mir gehts halt dadrum das im Endeffekt jeder der mit Dreamweaver umgehen kann die Templates in nem gewissen Rahmen editieren kann.

    Hast du denn auch ne Idee wie ich rauskriegen kann welche Elemente alle weg müssen um nen gewisses Feld zu löschen ?

    Ne Möglichkeit wär nen Platzhalter, wie:

    [!empty]
    #feldcode
    {Platzhalter}
    # /feldcode
    [/!empty]

    wobei mir das auch nicht so gefällt.
  • Was ich meine:

    jemand postet einen Gästebucheintrag, gibt allerdings keine ICQ-Nummer an.
    Da das (output)Template ansich aber absolut statisch ist könnte man den Platzhalter nur durch ein leeren String ersetzen.

    Eleganter wäre es das ganze Feld für die ICQ-Nummer zu löschen.

    Nun weiß ich aber auf PHP Seite nicht genau, wie viele HTML-Elemente ich dafür löschen muss, denn denkbar wäre z.B. :

    <p class="icqnummer">{ICQNUMMER}</p>

    oder aber sowas wie:
    <p class="icqnummer"><span>{ICQNUMMER}</span></p>

    Ich weiß ja nicht genau was der Designer da am ende verbocken wird.

    Jetzt ist die Frage wie ich am besten raus finde welche Tags weg müssen um das Feld was nicht gebraucht wird zu löschen.

    Mir fällt da nur ein die "Felder" zu kennzeichnen.

    Beispiel:

    {ICQFIELD}<p class="icqnummer">{ICQNUMMER}</p>{/ICQFELD}

    Und wenn halt der Platzhalter ICQNUMMER leer ist, soll das ganze Feld gelöscht werden.
    Das ist mir allerdings irgendwie zu kompliziert, hab aber noch keine bessere Idee.
  • In Smarty ginge das so:

    {if $ICQNUMMER != ""}<p class="icqnummer"><span>{$ICQNUMMER}</span></p>{/if}


    Aber solange du du tags nicht markierst, ist die Sache schwierig. Du könntest dir ne Methode Schreiben, die zwei Felder verbindet. Sowas wie

    brotherFields('ICQFILED', 'ICQNUMMER')


    dann kannste dein Template nach leeren Vars ruchsuchen, gucken ob sie "verbrüdert" sind und dann das komplette Feld löschen.

    Aber ich weiß immer noch nicht, warum man das Rad 2x erfinden will. Smarty is echt weit entwickelt, und wenn dir daran was nicht gefällt, könntest du ja auch einfach Smarty anpassen...

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

  • Naja im Grunde wollte ich versuchen ohne ne Art "Templatesprache" auszukommen.

    Vorteil wäre 0-Einarbeitung gewesen, für Leute die mit z.B. PHP nicht viel am Hut haben und grad mal HTML können.
    Und man hätte größtenteils WYSIWYG support.

    Da sich das ganze aber als schwierig rausstellt, werd ichs wohl verwerfen.
  • Habe eine solche Template-Engine geschrieben, wobei ich derzeit an der Version 2.2.0 arbeite (die nochmals viele neue coole Features bringen soll). Die ältere Version funktioniert grundsätzlich so, dass man Variablen in verschiedenen Templates ersetzen lassen kann und der große Burner: Blöcke. Diese sind z.B. so dargestellt:
    {% blockname %}
    {%blockname.textvar%}

    {% blockname %}
    Variablen oder Blöcke werden aus den Templates gelöscht, so sie nicht verwendet werden. Blöcke kann man beliebig oft erzeugen lassen, d.h. wenn ich nun einen neuen Block "blockname" erzeuge, mit der Variable "textvar" = "Mein Inhalt", entsteht daraus "Mein Inhalt
    ". Das Besondere an dem Ganzen ist, dass man es auch schachteln kann. Dann reicht also
    {% table %}
    <TABLE {%table.infos%}="">
    {% tr %}
    <TBODY><TR {%tr.infos%}="">
    {% td %}<TD {%td.infos%}="">{%td.content%}</TD>{% td %}
    </TR>
    {% tr %}
    </TABLE>
    {% table %}
    Für eine Erzeugung beliebig vieler Tabellen untereinander, denen man unterschiedliche Styles und Inhalte zuweisen kann.

    Letztendlich läuft alles ohne weitere Templatesprache ab, außer dass eben Variablen ohne Leerzeichen in {%a%} geschrieben werden, Blöcke mit Leerzeichen {% a %} und Variablen von Blöcken mit dem Blocknamen, einem Punkt und dem Variablennamen {%a.var%}

    Die neue Version wird noch einige Erweiterungen haben, obwohl die Alpha-Version bisher noch etwas langsam ist. (Die Version T-REx 2.1 läuft meist mit einer Parse-Zeit von ~0.2sek, was akzeptabel bzw nicht unangenehm ist). Die Alpha-Version von 2.2.0 läuft im Moment aber auf meinem lokalen Rechner noch im ersten Aufruf mit ~1sek und im zweiten Aufruf dann aber mit ~0.2sek, was stören ist. Ich vermute bisher, dass es einfach der Unterschied von 300 Zeilen mehr Code und noch etwas mehr Komplexität ist..
    T-REx soll sich vor allem durch Flexibilität auszeichnen, weil man es schnell auf eigene Systeme angleichen kann und z.B. in der neuen Version Funktionen zur Fehlerbehandlung oder zum Kompilieren selbst definieren kann (die dann aufgerufen werden).
    Ein WYSIWYG hat es somit nicht und gilt damit wohl nicht wirklich als TemplateEngine, ich finde aber, eine reine php-Bibliothek, die im Hintergrund zuverlässig arbeitet und effizient ist, ist weit aus besser als ein unnötiger großer Haufen an Code ;)


    Falls es dich interessiert: mail@julian-stier.de



    lG


    EDIT: Die Werte liegen je nach Größe der Templates natürlich anders. Die Klasseneinbindung + Instanzierung benötigt ~0.002sek - 0.004sek; je nach Größe der einzulesenden Templates und Größe der Blöcke braucht es dann nochmals dementsprechend zw. ~0.0001sek - 0.1sek :)

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