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
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
