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