[TYPO3-german] Diverse Fluid Extensions

[Cedric Ziel]

Hallo Bernd,

> Zu diesem Bereich gab es auf dem TYPO3Camp in Essen einige Vorträge 
> und Diskussionen. meist eher spontan, so dass es auch keine Slides 
> dazu gibt.
> 
> Welche dieser Extensions die geeignetste ist muss jeder für sich 
> entscheiden. Aber sicherlich ist da im Moment noch vieles in Bewegung.
> u.a. [1]
> 
> fluid/flux sind einfache Möglichkeiten für Konfiguratoren neue CEs 
> zu definieren und sie den Redakteuren zur Verfügung zu stellen.
> 
> ein aktueller Nachteil vieler dieser Extensions:
> die individuellen Konfigurationen und Werte der CEs werden als große 
> XML-Struktur in einem Datenbankfeld pi_flexform gespeichert. gezielte 
> Abfragen/ Modifikatioenen einzelner Feldwerte sind damit mit purem 
> SQL nicht mehr so einfach möglich. (Ein großes Manko, mit dem sich 
> schon TV inkompatibel zum Core gemacht hat)
> 

Wir planen aktuell, wie man flux storage agnostisch auslegen kann, um 
FlexForms loszuwerden, oder zumindest mit flux auch andere 
Speicherarten einzusetzen.

> Ich persönlich wünsche mir noch ein Tool, um individuelle CEs mit 
> std-DB-Feldern zu generieren und von diesem (für Abfragen zu) 
> komplexen XML weg zu kommen.  [1]
> Einige Extension-Autoren haben das auch schon erkannt und versuchen 
> in diese Richtung zu entwickeln. Das wird dann aber Konvertierungen 
> erfordern für die Realisierungen, die es im Moment gibt.
> Und es wird dann Sackgassen geben wenn eine Extension(-Technik) dann 
> nicht mehr weiter entwickelt wird: Claus Due hat z.b. angekündigt 
> FluidContent nicht mehr weiter zu entwickeln, wenn bestimmte Features 
> in Gridelements / Themes verfügbar sind.
> 
Der Gedanke hinter deinem letzten Ausspruch geht ein wenig tiefer: 
fluidcontent ist ein sehr loser Aufsatz auf flux (vgl bitte 
https://github.com/FluidTYPO3/fluidcontent/tree/master/Classes). 
Fluidcontent ist ein Plug-In für flux, und verdrahtet mit einem 
ConfigurationProvider die entsprechenden Felder-nicht mehr, und nicht 
weniger. Jede andere Extension kann daher hergehen und Felder mit flux 
verdrahten. Das ist auch der Gedanke, der hinter dem "Aufgeben von 
fluidcontent" steckt. Wenn Themes sich dort einhängt, wäre das eine 
Drop-In Solution und könnte fluidcontent Nahtlos ablösen; ohne 
Reibungsverlust-mit der gleichen Logik und flux im Hintergrund (das ist 
der Plan). Das bedeutet, also das sich niemand Gedanken über 
"zukünftig nicht tragbar" machen muss-weil themes genau an der Stelle 
einsetzen würde, an der fluidcontent stand/steht.

Damit wären wir in der Lage, fluidcontent zu droppen und uns auf das 
Kernprodukt-flux-zu konzentrieren, denn flux hält alles zusammen.

Viele Grüße,
Cedric