[TYPO3-german] Diverse Fluid Extensions

Thu Dec 19 13:01:35 CET 2013

Hallo Jan,

als Kollaborator an dem FluidTYPO3 Projekt bin ich vielleicht nicht 
ganz objektiv-ich bitte das zu entschuldigen und hoffe, dass ich dir 
trotzdem Input geben kann.

Trotz alledem solltest Du, wenn Du mit fluid Templates baust, mal einen 
Blick auf die Extension "vhs" werfen. Hier haben wir einige Utility 
ViewHelper zusammen getackert, die einem das Leben als 
Integrator/Entwickler leichter machen.

Zum Thema:
Wenn man mit TYPO3 Websites erstellt, dann hat man immer schon das 
Problem gehabt, das es keinen Vernünftigen Weg für Strukturelemente 
gibt. Diese Strukturelemente sind neben den FCE's einer der Gründe 
für die massive Verbreitung von TemplaVoila gewesen. Diese 
Strukturelemente sind aber (leider) bei der Konzeption des CMS' back in 
the days nicht beachtet worden-das Produkt kommt auch aus einer Zeit, 
als Spalten-Elemente eher hässliche Trickserei gewesen sind. Das 
Datenbankmodel der Kerntabellen pages und tt_content hat (so behaupte 
ich) immernoch viel mit diesem Start gemeinsam; daher fehlt dem Kern 
die Möglichkeit, solche Elemente zu erstellen.

Das Team um Jo Hasenau leistet gute Arbeit, Strukturelemente 
normalisiert in der Datenbank abzulegen und bietet mit gridelements(2?) 
eine gute Grundlage, um ordentliche Strukturen zu hinterlegen.
Strukturelemente sind auch nicht unser primäres Anliegen, wir freuen 
uns aber trotzdem, dass Kay Strobach und einige Andere mit THEMES daran 
arbeiten, eine Middleware (Gridelements, Flux) agnostische Möglichkeit 
entwickeln, die es erlauben wird, das Beste aus allen Welten zu nutzen.

gridelements oder THEMES als Metapaket (Was tut es, wie tut es das? 
Ralf, vielleicht kannst Du ja erläutern, was hier passiert-Du scheinst 
ein gefestigtes Bild zu haben; vielleicht kannst Du uns aufkären, 
warum es "besser" ist?) sind mE nicht besser oder schlechter, Sie 
erledigen ähnliche Jobs auf andere Arten und Weisen.

Der Kern der FluidTYPO3 Bestrebungen ist es, dem Entwickler schnell und 
einfach ein Interface für die Seitengestaltung zu bieten. Wir sind 
begeisterte Benutzer von fluid und kapseln sämtliche Funktionalität 
in fluid ViewHelpern (nicht exklusiv..). Wir möchten TypoScript 
einsparen, und durch fluid Konstrukte ersetzen. Als Beispiel möchte 
ich gerne angeben, was die einzelnen Extensions ausmacht:

flux: Flux ist der Kern und kommt von fluid flexforms. Flux ebnet den 
Weg, um mit fluid Flexforms zu schreiben. Flexforms als Kernkonstrukt 
in TYPO3 steuern das Backend und generieren über das TCA bspw 
sämtliche Formulare zu Entitäten. Da es hier aber, wenn man über 
einfache Formulare hinausgeht schnell unübersichtlich wird, bietet 
flux ein HTML Interface (fluid verwendet ja html namespaces), welches 
einfach zu bedienen ist, um flexforms zu generieren und mit 
Funktionalität auszustatten, für die man ohne flux viele Brücken 
schlagen müsste. (ZB ein Group Field, das es erlaubt News 
auszuwählen, und im Fluid View direkt die Extbase Entität zur 
Verfügung stellt).

fluidpages: Fluidpages erlaubt es, mit fluid Seitentemplates zu 
erstellen, die selbst bestimmen, wie viele ContentAreas in welcher 
Anordnung verfügbar sind-zur Laufzeit.
Ein einfaches, einspaltiges Template findet sich auf GitHub. 
(https://github.com/Ecodev/bootstrap_package/blob/master/htdocs/typo3conf/ext/speciality/Resources/Private/Templates/Page/1Column.html)
Was zuerst als Overhead angesehen werden kann, zeigt aber ganz gut, das 
dort direkt ein Formular mit weiteren Optionen eingebunden wird, das 
nachher im Rendering zur Verfügung steht.
Statt in einem separaten Datenbank Feld wird die Konfiguration im 
flexforms Feld gespeichert.

fluidcontent: Bietet eine einfache, aber schnelle und mächtige 
Möglichkeit um Flexible Inhalts- und Strukturelemente per flux mit 
Flexforms zu erstellen. (Kurze Antwort, aber goßer Impact ;) )

In jeder Extension bieten wir an, einen Controller Context selbst zu 
gestalten, das heisst, einen PageController für die Layouts, einen 
ContentController für die FCEs. Hier könnte (es gibt keinen Zwang) 
der Entwickler sich nach Belieben mit Extbase auszutoben, und 
Properties in den View einzutüten. Das bedeutet, was vorher sehr viel 
TypoScript benötigt hat, lässt sich (bekannter Weise) mit Extbase 
respektive fluid sehr viel einfacher lösen.
Und hier wird es etwas kompliziert: Der geneigte Integrator träumt 
wahrscheinlich in TypoScript und Extbase ist das große böse Monster. 
Der Punkt ist, dass wir sehr große Komplexität ermöglichen, dies 
aber keinesfalls als Normalfall ansehen. Der 08/15 Entwickler möchte 
schnell und einfach zum Ziel kommen. - Das ist der Grund, warum 
TemplaVoila so erfolgreich war, und auch heute immernoch ist. (Kein 
Bashing, aber viele Agenturen und Einzelkämpfer setzen es heute noch 
in neuen Erzeugnissen ein, weil Sie sich an das Schema gewöhnt haben) 
Wir ermöglichen die Nutzung von fluid in beinahe allen Bereichen und 
ermöglichen damit sehr schnelles, konsequentes Arbeiten in einem 
Kontext.

Um zum Schluss zu kommen:
Jeder muss für sich muss entscheiden, welches Gift für ihn das 
richtige ist. Da gibt es DCE, gridelements und flux-alle machen das 
Gleiche-irgendwie. Sie transformieren Flexforms in fluid properties, 
die im Template weiter verarbeitet werden können. gridelements ragt 
heraus mit einer hervorragenden Struktur für Strukturelemente-hier 
musst Du aber eigene Flexforms schreiben, wenn Du FCE's mit besonderen 
Eingabefeldern haben möchtest.

Der Kern an sich bietet nichts dergleichen an. Auch mit "nur fluid" und 
BackendLayouts fährst du in eine Sackgasse, also gibt es ein 
dringendes Bedürfnis nach zusätzlichen Konfigurationsmöglichkeiten. 
Wenn Du kein herausragender, schneller Entwickler bist, musst Du also 
selbständig die Datenbank Tabellen des Kerns erweitern und die 
passenden Formulare draufpacken. Willst Du das nicht, sondern einfach 
nur deine Arbeit erledigen-dann stehen wir gerne mit unseren Extensions 
parat. THEMES und gridelements bieten nicht ansatzweise die 
Möglichkeiten, die wir anbieten-das ist aber auch gar nicht die 
Intention. THEMES selbst ist in weiter Ferne und wird viel von unseren 
Extensions verwenden, daher schließt das Eine das Andere nicht aus. Es 
ist mE wichtig, diesen Punkt zu verstehen.

Ein weiterer Aspekt: Der geneigte Integrator verwendet eine ganze 
Heerschar an Extensions, die kleine Dinge erledigen, aber viele 
Probleme verursachen. Mit den genannten Extensions kannst Du dir die 
Teile sparen und einfach und sicher das Umsetzen, was dein Designer dir 
vorgelegt hat-weil Du aus dem Template heraus das System anzapfen 
kannst. Wir legen sehr viel Wert auf eine korrekte Benutzung der Core 
Apis, um sicherzustellen, dass das Ergebnis den Erwartungen entspricht.

Wir sind mittlerweile 5 Leute, die über GitHub an den Projekten 
kollaboriert-permanent, Tag für Tag. 
(https://github.com/organizations/FluidTYPO3)

Wir empfehlen, die Möglichkeiten mit gridelements für 
Strukturelemente zu nutzen, um irgendwo eine Normalisierung zu 
erreichen, aber für den Rest-ein Benutzerfreundliches Interface, 
Eingabemöglichkeiten für Redakteure und nicht zu letzt 
Geschwindigkeit in der Entwicklung sehen wir unsere Extensions als 
kleinstes aller Übel an. Für 95% aller Anwendungsfälle, auch im 
Team, würde ich die Suite jedem ans Herz legen.

Das Bootstrap Package (http://get.typo3.org/bootstrap oder 
https://github.com/Ecodev/bootstrap_package/) bietet einen leichten 
Einstieg in die Materie und lohnt mit Sicherheit einen Blick.
Die ViewHelper Referenz (https://fedext.net/viewhelpers.html) bietet 
einen guten Überblick, auch über die Core ViewHelper.

Ich hoffe, ich habe niemandem auf die Füße getreten und würde mich 
über einen Dialog freuen.

Viele Grüße,
Cedric