nicht angemeldet
<!-- 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 Callaborate-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.)
Man kann durchaus auch PHP-Code in einem Template gegen erlaubte Bezeichner/Operatoren validieren (ausgehend von token_get_all).
Das ist mit IMHO einfacher/sicherer als die Umsetzung einer weiteren i.d.R. unzulänglichen Template-Syntax.
Für ein Template reichen als "Whitelists" meist ein paar Operatoren/Token (+-?: etc.),
die Bezeichner der alternativen Syntax (foreach: if: etc.),
sowie einige ausgesuchte Funktionen zur Zeichen- und Zahlenformatierung bzw. Berechnung.
Die sich daraus ergebenden Vorteile sind:
1. Kunden mit PHP-Kenntniss müssen keine weitere nutzlose Syntax erlernen
2. Kunden können ggf. notwendige Berechnungen/Formatierung vornehmen die ein Template-System mit eigener Syntax irgendwie nachbilden müsste
3. Validierte Templates lassen sich direkt mit include einbinden, wodurch die Vorteile eines Opcode-Caches genutzen werden können*
4. Templates mit PHP-Code Einschüben können in einem brauchbaren Editor sinnvoll ausgezeichnet/überpüft/gefaltet werden
*Template-Systeme müssen dazu zusätzliche Dateien erzeugen