Strategiefrage FLUID

[tsk]

Hallo zusammen,

ich denke, für jeden alten TYPO3 Hasen kommt irgendwann der Tag, dem bislang hoch geschätzten TemplaVoila adieu zu sagen. Das dies mit einem weitgehenden Totalverlust an langjähriger Arbeitsleistung einher geht, brauche ich wohl niemandem zu erklären. Prall gefüllte FCE Bibliotheken werden schlagartig (weitgehend) wertlos.

Der Ersatz des Seiten-Templates durch Fluidtemplate ist banal, das Ergebnis im BE sogar überzeugender. Bleiben also die selbst zu erstellenden Content Elements, ohne die es in Zeiten von Responsive Layouts und hoher Kundenerwartungen nicht geht.

Kramt man hier im TYPO3 Fundus, so findet man wohl folgende sachdienliche Extensions oder Methoden:

• Gridelements
• FED/Flux/Fluid Content Elements
• Eigene Extension

Die "eigene Extension" empfinde ich hier nicht als probate Lösung, denn eigene Extensions sollten Funktionalität und nicht banale Struktur bieten. Bleiben zwei andere Varianten. Gridelements und die FED Schiene. Während Gridelements auf Forge als direktes Projekt unter TYPO3 4.7 geführt wird, erscheint FED eher als "Fremdkörper". In den Mailing Listen findet man große Begeisterung für beide Wege, aber auch gravierende Probleme mit beiden. Zwischen den Zeilen vernimmt man dann etwas, was klingt wie "FED braucht man nicht". Andererseits überzeugen die auf Forge genannten Gruppenmitglieder in beiden Fällen. Alles gute und geschätzte Entwickler.

Mein Credo ist, alles, was ich nicht brauche, ist gut. Würde ich in der Entwicklung von TYPO3 der letzten zwei Jahre noch irgend eine nachvollziehbare Strategie erkennen, so müsste ich jetzt nicht fragen. Ich erlebe aber mit jeder neuen Release den harten Bruch mit alten Konventionen. Zahllose Entwicklergruppen arbeiten an ambitionierte Inselprojekten, die dann mit dem Rest nicht können. Ein Manifest tut etwas, was Manifeste sonst nie tun: Es wird durch Wischiwaschi ersetzt. Als professioneller Nutzer sucht man nur noch Lösungen für Probleme, die es früher nie gab - und verliert so die Zeit für den Broterwerb. Es wäre der pure Horror, jetzt auf eine Extension zu setzen, die dann irgendwann im releasebedingtem Orkus der Geschichte verdampft.

Auch bei TemplaVoila gab es bereits ein TemplaVoila Framework - und ich bin heute sehr froh, mich damals nicht dafür entschieden zu haben. Beherrscht man TV, so braucht man kein TV Framework. Punkt.

Sowohl Gridelements als auch FED scheinen Core-DB's zu verändern - was übel enden kann, im Falle von Updates. Wie geht Ihr mit dieser Frage zur Zukunftssicherheit des jeweiligen Weges um.

Danke für allen Input,

Thomas

[# eof]

Hallo Thomas,

ich stelle mir aktuell die gleiche Frage. Zudem habe ich in den letzten paar Jahren wenige TYPO3 Projekte gemacht, sodass auch TYPO3-Neuerungen wie die Backend-Layouts für mich neu sind. Wie ich das verstehe sind die Backend-Layouts im Vergleich zu den Gridelements ja für eine generelle Einteilung der Seite wohingegen die backend-Layouts ähnlich wie eigene FCE über TV nach der initialen Konfiguration flexibel beliebige Schachtelungen auf der Seite zulassen, oder?

Hast Du für Dich denn jetzt schon einen Weg gefunden? Ich habe mit den gridelements gestern etwas rumprobiert und das scheint ähnlich gut wie tv-fce zu funktionieren. Gibt es denn noch Alterantiven Inhalte ähnlich wie in einer Zeitung in Gridspalten zu arangieren? Mich würde auch sehr interessieren wie die anderen Board-User das machen.

Viele Grüße,

#eof

[tsk]

Hallo #eof


ja, ich habe jetzt meinen Weg gefunden – auch wenn er mich nicht 100% glücklich macht. Grundsätzlich muss man sagen, dass zum heutigen Zeitpunkt und mit heutigen Alternativen TemplaVoila nicht 100% ersetzbar ist. Andererseits erscheint es mir sicher, dass spätestens mit Neos Feierabend mit TV ist. Mein Ziel war also, etwas zu nutzen, was halbwegs zu den neuen Paradigmen passt.


Das Seitentemplate von TV kannst Du ohne Einschränkungen durch FLUIDTEMPLATE und BE-Layout ersetzen. Ist sogar intuitiver als mit TV.


Reine Strukturelement FCE, wie Subcolumns/grids, kannst Du mit der Extension gridelements einfach ersetzen, allerdings unter Verzicht auf Versionierung und Workspaces. Mit etwas Nachdenken und mit Register Nutzung bekommt man sie auch semantisch korrekt hin (also anderer Wrap um Spalte 2 falls Spalte 1 leer ist).


Funktionale FCE, wie Accordions oder Tabs, gehen auch mit Gridelements (mit gleichen Einschränkungen wie vor), arten aber dabei in gewaltige Typoscript Orgien aus. Aber es geht.


Was wohl nicht so einfach geht ist die Mischung aus TV und Fluidtemplate. Auch Gridelements und TV sind nicht kompatibel.


Als Alternative habe ich mir noch Fed/Flux angesehen, aber es gefiel mir nicht, eine ganze Kette von abhängigen Extensions zu installieren, um in den Genuss von FCE zu gelangen. Dazu kam dann noch, dass bereits erste Versuche scheiterten (wahrscheinlich bedingt durch eine unsaubere Trunk Version).


Einfache Elemente habe ich auch durch eigene Extbase Entwicklung erzeugen können, aber Extbase erscheint mir so katastrophal schlecht dokumentiert, dass ich gleich die Lust verloren habe. Zumal mit jeder neuen Version plötzlich alles ganz anders ist. BE Programmierung scheint's gar nicht zu mögen und Performance ist damit auch ein Fremdwort. Kurz. M.E. eine Totgeburt.


Dieser ganze Krampf wäre natürlich überflüssig, wenn's im TYPO3 Core irgend eine Funktion für Multiple-Content geben würde. Aber eine solch wichtige Funktionalität überlassen die Core Leute gerne den Ext. Entwicklern.


Wenn Neos dann tatsächlich einmal marktreif wird, so ist eh alles ganz anders. Keine Rede mehr davon, Extbase Anwendung einfach zu portieren, denn Neos und TYPO3 4/6 haben keine gemeinsame Basis mehr, keinerlei vergleichbare Konzepte. Da gibt es keinen Raum für Backports.


Ich habe derzeit noch die größte Hoffnung in Gridelements. Dicht am Core, kein Extbase und Teil eines Crowdfunding Projekts, um Defizite der aktuellen Version auszumerzen. Zusammen mit FLUIDTEMPLATE könnte das dann ein wirklicher TV Killer werden.


Grüße,


Thomas