nicht angemeldet
Hello,
<!-- repeat_form--><!--{RECNO}--><!-- of form opinionbook_list_static -->
<tr>
<td><!--{CALC_ENTRY_DATE}--></td>
<td><!--{OWNER}--></td>
<td><!--{SUBJECT}--></td>
<td><input type="submit" name="btn[view][<!--{RECNO}-->]" value="ansehen"></td>
</tr>
<tr>
<td colspan="4" style="white-space:pre;"><!--{CALC_CONTENT}--></td>
</tr>
Ich wollte das Rad nochmal erfinden und habe für unser kleines Collaborate-CMS ein Templatesystem gebastelt, dass es zulässt, dass die Templates vom Kunden erstellt werden, also auch per HTTP von einem entfernten Webserver geholt werden können (in der Regel von seinem). Und da darf ja dann kein aktiver PHP-Code mehr enthalten sein.
Für mich sieht das eher nach einem weiteren Dreieck aus das als Rad verkauft werden soll.)
Klar, du hast ja auch nur drei Ecken von unserem Vieleck gesehen bisher :-P
Man kann durchaus auch PHP-Code in einem Template gegen erlaubte Bezeichner/Operatoren validieren (ausgehend von token_get_all).
Man muss aber nicht, wenn man nicht will. Und der Anspruch dieses Systems ist nunmal die absolute Trennung von Daten und Formatbeschreibungssprache/Auszeichnungssprache. Das muss nämlich nicht HTML sein, es kann auch HSV-Form oder eine Ableger von RTF sein.
Das ist mit IMHO einfacher/sicherer als die Umsetzung einer weiteren i.d.R. unzulänglichen Template-Syntax.
Die Template-Syntax ist nachher ganz einfach. Alle in Templates enthaltenen Daten werden durch Platzhalter ersetzt. Wir haben uns jetzt für die Schreibweise |{PLATZHALTER(index)}| entschieden. Es gibt bisher nur einen geschützten Platzhalter, nämlich |{REPEAT}|. Bislang lösst sich so alles darstellen. Wir sind aber noch nicht ganz fertig - das räumen wir durchaus ein. Vielleicht kommt ja nuoch eine "Über-Geraschung".
Für ein Template reichen als "Whitelists" meist ein paar Operatoren/Token (+-?: etc.),
Den Zusammenhang habe ich jetzt nicht verstanden. Wie meinst Du das?
die Bezeichner der alternativen Syntax (foreach: if: etc.),
Brauchen wir nicht.
sowie einige ausgesuchte Funktionen zur Zeichen- und Zahlenformatierung bzw. Berechnung.
Brauchen wir auch nicht, weil alles Absonderliche, was nicht durch die Auszeichnungsprache erledigt werden kann, unterlassen werden muss. Ganz simple Ausnahmen bestätigen, wie immer, die Regel.
Die sich daraus ergebenden Vorteile sind:
- Kunden mit PHP-Kenntniss müssen keine weitere nutzlose Syntax erlernen
Müssen sie bei uns auch nicht.
- Kunden können ggf. notwendige Berechnungen/Formatierung vornehmen die ein Template-System mit eigener Syntax irgendwie nachbilden müsste
Versstehe ich jetzt nicht.
- Validierte Templates lassen sich direkt mit include einbinden, wodurch die Vorteile eines Opcode-Caches genutzen werden können*
Der Kunde kann sein Template mittels "validator.w3.org" (kennst Du?) validieren. Wenn es sein muss, kann unser System das bei Anmeldung des Templates auch.
- Templates mit PHP-Code Einschüben können in einem brauchbaren Editor sinnvoll ausgezeichnet/überpüft/gefaltet werden
Unsere Templates enthalten nur die Elemente der jeweiligen Formatbeschreibungs- oder Auszeichnungssprache, können also keine "aktiven" Teile enthalten. Sollten sie das doch tun, dann werden die einfach als Quellcode mit ausgegeben, aber nicht interpretiert.
*Template-Systeme müssen dazu zusätzliche Dateien erzeugen
Wir müssen nichts zusätzlich erzeugen.
Unsere Devise ist: "Keep it simple and simplify" oder wie auch immer Du "KISS" übersetzen magst.
Die Daten liefern wir, die Darstellung der Kunde.
Wenn er sein HTML-Template und sein CSS nicht valide hält, können wir das zwar feststellen, wollen wir aber gar nicht unbedingt. Ist doch seine Sache, wenn seine Webseite blinkt und zwitschert, Hauptsache die von uns zu liefernden Daten stimmen.
Während Andere "Web 2.0" basteln, haben wir uns mit "Web Client-Server" beschäftigt :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
