Refactoring T3TWIG

[digedag]

Refactoring T3TWIG

[rengaw83]

Eine Anlehnung an das FLUIDTEMPLATE finde ich gut, ist aber meines Erachtens weitaus komplexer als obiges Beispiel.
Folgendes Beispiel wird oft verwendet, hat mit dem obigem nichts gemein::

lib.stdContent = FLUIDTEMPLATE
lib.stdContent {
    templateName = Default
    templateRootPaths {
        10 = EXT:frontend/Resources/Private/Templates
        20 = EXT:sitemodification/Resources/Private/Templates
    }
    variables {
        foo = bar
    }
}

Das Template lässt sich bei Fluid über templateName / templateRootPaths, template oder file angeben.
Weiter müsste sich beim context bzw. den variables um das Rendern der Libs bzw. ContentObjecte gekümmert werden. Dies allerdings nur, wenn diese im Template auch benötigt werden, um unnötiges, ggf. resourcehungriges Parsing zu vermeiden. Das erachte ich dann für eher Schwierig (Makros, Includes, Extensions, etc.)

Die Umbenennung ist möglich, allerdings müssten dann die Bestandsprojekte angepasst werden, oder es gibt einen Alias.

Das Twig cObject baut aktuell direkt auf den bestehenden Renderer von T3TWIG auf.
Dieser wiederum baut aus historischen Gründen auf rn_base auf und dessen template Konfiguration.
Der bisher verwendete Key template wird auch bei Fluid verwendet, kann also bleiben, optional könnte der Key file bei Twig ergänzt werden. templateRootPaths würde ich wahrscheinlich erst mal weglassen.

Die Daten, welche aus dem TS an Twig weitergegeben werden, können gern in variables gesteckt werden, allerdings müssen auch hier die Bestandsprojekte angepasst werden.

[digedag]

Also es geht mir nicht darum, das 1-zu-1 zum FLUIDTEMPLATE aufzubauen. In TYPO3 gibt es die Contentobjekte TEMPLATE und FLUIDTEMPLATE. Dann sollte das Objekt für Twig IMHO entsprechend auch TWIGTEMPLATE heißen. Und file ist meiner Ansicht nach auch der bessere Name für die Pfadangabe zur Datei. Kann ja auch als Alias hinzugefügt werden.

Die Werte für den Twig-Context sollten in der Struktur eine Ebene tiefer stehen, damit es keine Kollision zu anderen Angaben (template/file) gibt. Ob das dann context oder variables heißt, ist mir eigentlich egal. Hier würde man natürlich vorhandene Installationen anpassen müssen.
Das die Objekte immer gerendert werden müssen und eine Prüfung der Verwendung nicht möglich ist, liegt in der Natur der Sache. Aber eben auch in der Verantwortung des T3-Admins.

Die templateRootPaths sind bei Twig ja nicht relevant. Es gibt aber andere Konfigurationen für Twig, die später mal noch aufgenommen werden können.

[digedag]

Ich hab jetzt erstmal soweit drin und auch dokumentiert. Ein paar Dinge würde ich aber gern noch ausbauen, weil mir da zuviele unnötige "Fallbacks" drin sind.
Aber der Reihe nach. Das Contentobject heißt nun zusätzlich auch TWIGTEMPLATE. Die Template Datei sollte mit dem Attribut file angegeben werden. Das Attribute template mit allen seinen Fallbacks funktioniert aber immer noch. Die würde ich aber gern entfernen.

Die Daten für den Context werden nun unterhalb des Attributs context geladen. Wird dieses Attribut nicht gefunden, dann wird wie bisher der Inhalt von cObj->data flach in den Context gelegt. Das war's dann aber auch. Ist context dagegen vorhanden, dann werden die Daten wie oben beschrieben ausgewertet und dem Context hinzugefügt. Außerdem werden immer drei reservierte Datensätze eingebunden:

• data -> Der aktuelle Inhalt von cObj->data
• current -> Der Inhalt von cObj->data[cObj->currentValKey]
• page -> der Record der aktuellen Seite

Wie gesagt, diese Daten gibt es nur, wenn context konfiguriert wurde. Wenn wir den alten Weg entfernen, dann kann das natürlich immer gemacht werden.

Zusätzlich habe ich mir noch die Einbindung von anderen Templates angesehen. Es gibt nun einen speziellen Loader für das TYPO3 Filesystem. Damit kann man Templates innerhalb von Extensions und im fileadmin ansprechen. Der Namespace für den fileadmin ist @fileadmin. Die Extensions werden mit @EXT:extName angesprochen. In den Extensions müssen die Dateien immer unterhalb von Resources/Private/ liegen. Dann kann man wieder frei wählen. Ist ausführlich in der Doku beschrieben.

[rengaw83]

Im TwigContentObject sollten wirklich nur die Entsprechenden Daten aus dem Context gesetzt werden. Nicht auch die Page.

Die TSFE ist bereits von überall aus im Template verfügbar und damit auch die Page: tsfe.page.alias. Siehe TsFeExtension

Ich habe das erst mal raus genommen. Ggf kann man die Page direkt in der Extension mit setzen, das wäre dann allerdings doppelt und man hätte nicht die Möglichkeit die variable page unter context zu setzen.

[RocKordier]

v1.0.0 was released several days ago. We can close for now, i think.