[TYPO3-german] gridelements vs fedext

[JoH asenau]

> Die Inhalte der FCE's werden in XML gehalten und im Prinzip ähnlich wie
> bei TemplaVoila in FlexForms gespeichert. Was jedoch ist die Alternative?
> Seit dem TYPO3Camp in München bin ich gedanklich in einer großen
> Zwickmühle, weil ich den "Fehler" gemacht habe, und mich von Christian
> Müllers Neos Sessions beeindrucken ließ. Auch wenn Gridelements, was
> Kind-Elemente (und hier wirklich Elemente, kein FlexForm Inhalt-der wird ja
> wie bei fluidcontent als XML in die Datenbank geschoben) eine
> Normalisierung anstrebt und damit tendenziell schonmal bei
> Strukturelementen punkten kann; so bleibt immer die Frage nach flexiblen
> Inhalten. In Neos wirkt alles natürlich. Im CMS ist alles nur
> aufgeflanscht. - Man wählt also letzten Endes zwischen Pest und Cholera.
> DCE, gridelements und fluidcontent müssen hier mit XML in der Datenbank
> arbeiten, was heutzutage keinen spürbaren Geschwindigkeitsnachteil hat.

Den Punkt würde ich gern ein wenig beleuchten.

Gridelements ermöglichen zwar prinzipiell die selbe Verwendung von XML 
wie sie mit TemplaVoila eingeführt wurde, jedoch ist die Empfehlung, 
darauf so weit wie möglich zu verzichten. Es ist zwar bei kleineren 
Seitenbäumen mit wenigen Inhalten kein erheblicher aber ein messbarer 
Geschwindigkeitsnachteil, der sich speziell bei größeren Seitenbäumen, 
tiefer verschachtelten Container-Strukturen und seiten- sowie 
containerübergreifenden Datenstrukturen immer deutlicher bemerkbar 
macht, je mehr Datensätze einbezogen werden müssen.

Während ich bei normalisierten Daten die volle Power der Datenbank mit 
Hilfe von JOINS nutzen kann, muss ich beim XML-Ansatz IMMER in den 
Inhalt einsteigen, ihn parsen, in Arrays wegschreiben, wieder auf die 
Datenbank zugreifen, erneut parsen, sortieren etc.

Ein simples Beispiel ist ein Teaser-Menü das auf das jeweils erste 
Inhaltselement einer Seite zugreift. Es gibt aber sicherlich noch 
weitaus komplexere Anwendungsfälle.

Ursprünglich wollten wir bei Gridelements gänzlich auf XML verzichten 
und hatten das Flexform-Feld nur für die Migration von TV hin zu GE 
vorgesehen. So konnte man mit einer einfach Kopie der Strukturen in 
dieses Feld relativ einfach überprüfen, ob die verknüpften 
Inhaltselemente noch vorhanden sind und das Feld danach mit einem 
SQL-Query löschen.

Wir haben danach festgestellt, dass es aber durchaus sinnvoll sein kann, 
das Feld für Konfigrationszwecke - und nur dafür(!) - zu erhalten. 
Inhalt hat dort nur wenig zu suchen und kann fast IMMER über eine 
saubere Verknüpfung von selbst erstellten oder existierenden 
Elementtypen über tt_content normalisiert werden.

Wer dafür unbedingt eigene Inhaltselementtypen benötigt, sollte im 
Zusammenhang mit Gridelements eher den Weg über TCA gehen und sich einen 
eigenen CType definieren. Ein relativ simpler Wizard, der ähnlich wie 
beim FORMs-Projekt eine freie Zusammenstellung und Beschriftung 
existierender Felder ermöglicht, wäre dabei natürlich hilfreich, aber 
auch so sind Types und Palettes kein Hexenwerk. Da ist nichts 
aufgeflanscht und für 90% der Anwendungsfälle sollte die bestehende 
Anzahl von Feldern in tt_content ausreichen.

Wir arbeiten aber noch an einer weiteren Lösung, die eine minimierte 
Tabelle zur Erzeugung von Inhalts-Gruppen aus abstrakten Einheiten 
ermöglichen wird. Halt nicht Text, mit Headline mit Bild in einem 
Datensatz sondern: Struktur + Text(e) + Headline(s) + Bild(er) + X, 
wobei die letzten 4 Datensätze aus der minimierten Tabelle sind. Das 
kommt dem Node-Konzept von Neos weitestgehend entgegen.

Im November wird's dazu einen weiteren Sprint geben. Termine gibt's hier:
http://doodle.com/kpqpkd73qn8r7g46

Es bleibt spannend

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com