Templates - Syntax und Eigenschaften

[Zeichen32]

jspit ah ok - Ich glaube, ich habe es jetzt verstanden. Ob man das jetzt Template Engine oder Template System nennen möchte sei mal dahin gestellt.

Allerding finde ich diese Konstruktion aus meiner Erfahrung heraus super umständlich. Und Du hast gegenüber einer reinen Template Engine rein gar nichts gewonnen. Du hast lediglich View-Logik auslagerst. Vielleicht übersehe ich etwas Grundlegendes, aber anhand Deines Beispieles sehe ich keine Vereinfachung oder Einsparung, sondern gesteigerte Komplexität.

Nennt man das nicht auch das View Helper Pattern? Ich meine mich zu erinnern, das es etwas ähnliches in Magento gibt, wo man die Template Blöcke über eine XML Datei konfiguriert und zusammenbaut und dann zu jedem Template ein ViewHelper gibt, welcher die Logik beinhaltet.

[jspit]

jspit Ob man das jetzt Template Engine oder Template System nennen möchte sei mal dahin gestellt.

Nun für das Kind einen neuen Namen zu erfinden wollte ich auch nicht. Ist ja auch nicht wirklich etwas neues was ich da treibe.

jspit
Allerding finde ich diese Konstruktion aus meiner Erfahrung heraus super umständlich. Und Du hast gegenüber einer reinen Template Engine rein gar nichts gewonnen.

Kann ich nicht beurteilen ob dieser Anwendungsfall z.B. mit twig weniger umständlich aussehen würde.
Diese Klasse soll mein altes TinyTemplate mal ersetzen. Das dort integrierte Caching ist überflüssig (PHP 7 ist schnell genug) und auch die Templatesektionen habe ich nie gebraucht.
Neu gegenüber TinyTemplate ist die Möglichkeit des Zugriffs auf Arrays/Objekte und die Filter/Funktionen.

jspit Du hast lediglich View-Logik auslagerst. Vielleicht übersehe ich etwas Grundlegendes, aber anhand Deines Beispieles sehe ich keine Vereinfachung oder Einsparung, sondern gesteigerte Komplexität.

Ist mir klar das der Aufwand auf PHP-Seite etwas höher ist. Die (meine) Templates sind ja fast reines HTML und enthalten weder Code noch Anweisungen wie extends oder include die wieder Abhängigkeiten erzeugen.
Wenn ich konsequent mit Defaultwerten arbeite kann ich die Templates sogar schon ohne ein assign validieren.
Wie schon gesagt habe ich nicht das Ziel ein Templatesystem zu schaffen was mehr kann als die gängigen. Ich brauche das hauptsächlich für Formulare um das ganze HTML von meinem PHP-Code fernzuhalten.
Wo es bei den Formularen dynamisch wird z.B. bei den Auswahllisten (Select) kommen wieder Generatoren zum Einsatz die einem Platzhalter einfach zugewiesen werden.
So eine index.tpl.html existiert auch nur hier und in der Masse meiner Applikationen nicht. Auch dafür habe ich auch einen Generator.

[jspit]

Es soll ein primitives Affenformular erzeugt werden, das bei Eingabe eines Datums und einer Anzahl Tage das Enddatum berechnet.
Ich denke mal das könnte so ähnlich auch mit Twig laufen.

Genau das habe ich jetzt mal unter W10 probiert . Die Templates konnte ich ohne Änderungen aus #14 übernehmen. Der PHP Code sieht für die Ausgabe mit Twig jetzt so aus:

//Ausgabe

$twigLoader = new FilesystemLoader(__DIR__.'/../templates');
// Instantiate our Twig
$twig = new Environment($twigLoader);

$assignForm = [
    'post' => $formVal, 
    'enddate' => $endDate
];

$tplform = $twig->render('form_date.tpl.html',$assignForm);

$assignIndex = [
    'title' => 'first twig test',
    'formular' => $tplform
];

$htmlMain = $twig->render('index.tpl.html', $assignIndex );

echo $htmlMain; 

Zusätzlich wird ein Autoloader benötigt. Wenn Twig per Composer installiert wird sollte dieser auch benutzt werden. Bin positiv überrascht, das beide Varianten ein absolut identisches Verhalten zeigen.
So wird z:b: auch unter twig ein DateTime-Objekt vom Filter date richtig erkannt und verarbeitet
Als nächsten Schritt werde ich das mal auf einen Raspi versuchen und die Ergebnisse dann vergleichen.

[Gast]

Hm... Aber könntest Du nicht direkt in Deinem Twig-Template auf das Form-Template referenzieren, ohne wie hier den Umweg über diese PHP-Date zu gehen? Wenn ich Deinen Code richtig interpretiere, benötigst Du dieses Stück Code wieder und wieder. Da würde eine generische Lösung doch eh mehr Sinn machen.


Noch eine andere Frage, vielleicht habe ich es einfach nicht begriffen: Was ist die Stoßrichtung dieses Threads? Wolltest Du jetzt was zeigen oder was wissen oder was diskutieren?

[jspit]

Stoßrichtung: 60% was wissen (über Twig), 30% diskutieren + 10%zeigen.

Im Twig-Template kann ich wahrscheinlich auch das Form-Template referenzieren. Da hat Twig sicher nicht nur eine Möglichkeit. In meinem Template gibt es nichts dafür. Hab da für Twig was von include gelesen. Die Wirkung dürfte so sein wie bei PHP. Welche Möglichkeiten gibt es noch (Stichpunkte reichen mir) ?

Was ich spare ist die eine Zeile mit $tplform. Die Platzhalter aus dem Form-Template muss ich dann ja auch füllen. Das bedeutet in der Praxis das $assignIndex wird entsprechend größer.
Als großen Nachteil bei dieser Variante sehe ich das ich jetzt 2 Templates durschauen muss um zu sehen welche Platzhalter ich mit PHP füllen muss.

Wie stelle ich es an wenn ich Form + Ergebnis nicht immer zusammen anzeigen möchte. Also Schritt 1 nur die Form und nach dem Ausfüllen nur das Ergebnis. Dann muss ich wohl im Twig-Template eine entsprechende Logik implementieren und die Daten als mehrdimensionales Array übergeben?

Mir ist auch nicht klar wie folgendes bei Twig realisiert werden kann: Ich brauche das form_date.tpl.html jetzt zwei mal im Main-Template für ein Start- und ein Enddatum. Ein zweimaliges include dürfte ausfallen. Ich muss ja die beiden (Sub)Templates mit unterschiedlichen Werten füllen.

Vermutlich habe ich fast alles was Twig betrifft einfach noch nicht begriffen.

[Zeichen32]

Am besten gliederst du deine Twig Templates mit Blöcken. Diese Blöcke kannst du auch einzeln überschreiben oder auch einzeln mit Use in andere Templates importieren.
Es gibt auch so genannte Macros, womit du wiederkehrende Element automatisieren kannst. Weiter solltest du auch gebraucht vom erweitern von Templates machen.

macro - Documentation - Twig - The flexible, fast, and secure PHP template engine (symfony.com)
block - Documentation - Twig - The flexible, fast, and secure PHP template engine (symfony.com)
use - Documentation - Twig - The flexible, fast, and secure PHP template engine (symfony.com)
extends - Documentation - Twig - The flexible, fast, and secure PHP template engine (symfony.com)

[jspit]

Ich glaube mit macros lässt sich ganz gut mit Twig umsetzen was ich oft brauche. Sehr hilfreich zum experimentieren finde ich dieses Twig-Fiddle. Habe da mal ein Beispiel für ein Macro reingestellt.
Werde meine Templateklasse aber erstmal auf den jetzigen Stand belassen und damit arbeiten. Bei Bedarf kann ich dann immer noch wechseln. Bedingt ist das durch die Spezifik meiner Zielsysteme.

[jspit]

Ein kurzer Zwischenbericht.

JspitTemplate ist zu 90% fertig. Habe erste Erfahrungen mit realen Anwendungen sammeln können.
Bei der Erstellung von Formularen haben sich einige spezielle Filter als sehr nützlich erwiesen.
Ein select z.B. in einem sogenannten Affenformular kann so notiert werden:

    <select name="selcar" size="1">
      <option value="0" {{post.selcar|selected("0") ?? "" }}>Audi</option>
      <option value="1" {{post.selcar|selected("1") ?? "selected" }}>BMW</option>
    </select>

Beim Erstaufruf ist POST leer und es kommt der Defaulteintrag hinter ?? zum Tragen. BMW ist als erstes ausgewählt.
Beim Wiederbefüllen wird je nach Auswahl für den Wert 0 oder 1 ein selected für Audi oder BMW ausgegeben.
Für das Array mit den Informationen aus $_POST ist in PHP nur eine Zuweisung für die Formularfelder notwendig,
vom Grundsatz

 ->assign(['post' => $_POST]) 

Die Notationen mit reinen PHP oder Twig sind da schon etwas aufwendiger.

[protestix]

Sieht gut aus, einzig die geschwungenen Klammern finde ich umständlich zu bedienen, kann man da nicht eine einfacher zu erreichende Taste wählen, ich bevorzuge da immer die Doppelraute Taste(##).

[rkr]

jspit Welches Problem soll deine Templete-Engine am Ende besser lösen, als bereits vorhandene Engines?

[jspit]

Für mich in erster Linie das Problem der Abhängigkeit von Fremdcode. Die Klasse Ist halt auf meine Bedürfnisse zugeschnitten, klein, überschaubar und bei Bedarf leicht erweiterbar.
Die Engine ist auch nicht neu. Genaugenommen ist es "nur" ein Refactoring mit kleinen Erweiterungen vom TinyTemplate. ( protestix : Dort wurden auch schon die geschwungenen Klammern benutzt und haben sich bewährt.)

Ich lasse mich hier auch nicht verführen um ein ein konkretes Feature zu finden welches vielleicht etwas besser als in bereits vorhandenen Engines gelöst ist. Weil da eben vieles auch Geschmackssache ist.

[rkr]

Weil da eben vieles auch Geschmackssache ist.

... was du nicht weißt, da du selbst sagst, dass du außer deiner Template-Engine praktisch keine andere Template-Engine gut kennst und anfangs sogar PHP selbst als vernünftige Alternative anerkennst. Jedenfalls lese ich das so raus.

Kannst du "Geschmackssache" etwas ausführen?

Im Bereich der MVC-Frameworks, DB-Klassen, Autoloader und Template-Engines wurde schon alles relevante erfunden. Aber eben noch nicht von jedem glaube ich...

[jspit]

Kann in der Tat nicht behaupten das ich andere Template-Engines gut kenne. Es ist aber nicht so das ich mich gar nicht mit anderen Engines beschäftigt habe. Zum Thema Geschmack.
Obiges Beispiel

    <select name="selcar" size="1">
      <option value="0" {{post.selcar|selected("0") ?? "" }}>Audi</option>
      <option value="1" {{post.selcar|selected("1") ?? "selected" }}>BMW</option>
    </select> 

ist für viele womöglich zu kompakt und schlecht verständlich. Das gleiche mit Twig könnte so aussehen:

    <select name="selcar" size="1">
      <option value="0"
         {% if post.selcar is defined and post.selcar== '0' %}
             selected
         {% endif %}
      >Audi</option>
      <option value="1"
         {% if (post.selcar is defined and post.selcar== '1')
           or post.selcar is not defined %}
             selected
         {% endif %}
       >BMW</option>
    </select> 

Bei Twig-Templates habe ich eben so meine Probleme durchzublicken. Wobei dies hier noch einfach ist.

[Zeichen32]

Also in Twig setze ich es meisten so um:

{% set post = app.request.post %}

{% for u in users %}
<option value="{{ u.id }}" {% if attribute(post, 'id')|default('') == u.id %}selected{% endif %}>{{ u.username }}</option>
{% endfor %} 

[rkr]

Kann in der Tat nicht behaupten das ich andere Template-Engines gut kenne. Es ist aber nicht so das ich mich gar nicht mit anderen Engines beschäftigt habe. Zum Thema Geschmack.
Obiges Beispiel

<select name="selcar" size="1">
<option value="0" {{post.selcar|selected("0") ?? "" }}>Audi</option>
<option value="1" {{post.selcar|selected("1") ?? "selected" }}>BMW</option>
</select> 

ist für viele womöglich zu kompakt und schlecht verständlich. Das gleiche mit Twig könnte so aussehen:

<select name="selcar" size="1">
<option value="0"
{% if post.selcar is defined and post.selcar== '0' %}
selected
{% endif %}
>Audi</option>
<option value="1"
{% if (post.selcar is defined and post.selcar== '1')
or post.selcar is not defined %}
selected
{% endif %}
>BMW</option>
</select> 

Bei Twig-Templates habe ich eben so meine Probleme durchzublicken. Wobei dies hier noch einfach ist.

Ist das dein Ernst?

Twig:

Init:

{% set cars = [{id: 1, title: '<bmw>'}, {id: 2, title: '<audi>'}] %}
{% set selected = 2 %} 

Template:

<select>
    {% for car in cars %}
        <option value="{{ car.id }}" {{ (car.id == selected) ? 'selected' : '' }}>{{ car.title }}</option>
    {% endfor %}
</select>

{# Alternativ: #}
<select>
    {% options(cars, selected) %}
</select> 

Ausgabe:

<select>
    <option value="1">&lt;bmw&gt;</option>
    <option value="2" selected>&lt;audi&gt;</option>
</select> 

Die < und > habe ich absichtlich eingebaut.

Und dein "|selected" kann man in Twig als einen Filter einbauen:

twig->addFilter(new TwigFilter('selected', fn($value, string $match) => strcmp((string) $value, $match) === 0 ? 'selected' : '')) 

Irgendwie sowas... nicht getestet.

Latte:

Init:

<?php
$cars = [
    ['id' => 1, 'title' => 'bmw'],
    ['id' => 2, 'title' => 'audi']
];

$selected = 2;

Template:

<select>
     <option n:foreach="$cars as $car" n:attr="value: $car['id'], selected: $car['id'] == $selected">{$car['title']}</option>
</select> 

Ausgabe:

<select>
     <option value="1">&lt;bmw&gt;</option>
     <option value="2" selected>&lt;audi&gt;</option>
</select>