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