[TYPO3-german] gridelements vs fedext

Andreas Becker ab.becker at web.de
Wed Sep 25 04:15:01 CEST 2013


Hi All

Vor ueber einem Jahr habe ich noch gerne mit TemplaVoila gearbeitet und es
wurde auch von der ueberwiegenden Mehrzahl unserer Kunden verlangt, nachdem
sie die traditionelle und TV Templating Methode im backend vergleichen
konnten. Insbesondere TemplaVoila Framework brachte sehr grossen Nutzen
fuer die Enduser, die in unserem Fall meist Redakteure sind. Das
Announcement von Toleiiv war im Grunde laengst ueberfaellig zu dem
zeitpunkt wo er es machte, da bereits zuvor TemplaVoila laufend nur
hinterher hinkte in der Entwicklung und auch IMHO vom Core immer wieder
(nett) ausgebootet wurde. Seine Entscheidung ist mehr als verstaendlich und
entspricht auch dem was andere, die inzwischen TYPO3 den Ruecken gekehrt
haben so von sich gaben. TemplaVoila ist einerseits die beste Erfindung und
das nutzer freundlichste System das in einem CMS (nicht nur in TYPO3)
vorhanden ist, doch es wurde vom CORE TEAM vor allem behandelt wie der
letzte Dreck um es auf ein Abstell gleis zu fahren. Leider wurde damit
nicht nur TV sondern IMHO ein Grossteil des TYPO3 Zuges quasi aus dem
Verkehr gezogen und vorallem vom Drupal ICE schlichtweg links liegen
gelassen.

Bereits seit laengerem habe ich daher mit Kay Strohbach an einer
Moeglichkeit weitergedacht wie man die Ideen von TemplaVoila Framework nach
dem was nun THEMES ist portieren kann. Und die Entwicklung ging dank Kay
rasend schnell und bereits vor fast einem Jahr hatten wir lauffaehige
Themes und inzwischen kann man auch WordPress Themes integrieren und die
alten TemplaVoila Themes aus dem FfTV 1 lassen sich auch einlesen. Alles
basierte bis dorthin auf Fluid.

Dann kamen die Developer Days und alles aenderte, bzw. ist verlangsamt
wegen langem warten auf patches und wie ich inzwischen sagen muss LEIDER.
Obwohl man mit THEMES auf Fluid bereits vor Monaten ein sehr gutes Thems
Repository haette aufbauen können, geschah das nicht da man nunmehr
Gridelements in alles integrieren wollte. Joey, ich weiss das du lange
daran gearbeitet hast und es mag auch gut sein, doch slowed es den gesamten
Prozess wieder komplett down.

Fakt ist, dass inzwischen mehrere Pakete herauskamen die ALLE auf Fluid
bauen und kein einziges setzt Grid Elements ein!

Seit Jahren redet man von Grid Elements doch bis zum heutigen Tage gibt es
kein brauchbares Paket das auch einmal den wirklichen Nutzen (ausser dem
das die Konkurrenz es liebt, weil sich TYPO3 damit selber ausbremst) zeigt.
War es urspruenglich nur fuer backend Designs gedacht obwohl TV das bereits
wesentlich besser konnte und immer noch besser kann, so soll es nun auch im
Frontend vorteile bringen - doch welche.

Mal Ehrlich: Immer wieder wird ueber XML und die Daten in einem einzigen
Feld geredet, doch eine wirkliche Alternative zu TV oder FLUID gibt es
schlichtweg NICHT und wird es wohl auch NIE geben, da es sich wohl nur mit
XML verwirklichen lässt : EIN NUTZER FREUNDLICHES TYPO3!

Was bringen Sprints fuer die man Geld sammelt aber die doch alles nur noch
weiter verzögern. Sollte TYPO3 6.2 LTS nicht im Oktober das Licht der Welt
erblicken? Was bringt da ein Sprint im November???

Wann erkennt das CORE TEAM endlich einmal die Realität und nicht nur deren
Wunsch Traum?
Der STANDARD:
http://templavoila.busynoggin.com - super nutzer freundlich und auch
developer freundlich. Das Beste was TYPO3 passieren konnte war dieses durch
die Web Empowered Church supportet und von Ron Hall entwickeltes Framework
for Templavoila. Seit ueber einem Jahr setzen wir bereits die Version 2
erfolgreich ein und die Kunden lieben es! Sie sind jedoch seit dem
Announcement von Toleiiv sehr verunsichert und einige bereits umgestiegen
auf zukunftstraechtigere Loesungen wie Drupal oder WordPress - das ja nun
auch von der WEC promoted wird auf deren Webseite.


Neben dem STANDARD fuer User Friendly TYPO3 Seiten gibt es viele weitere
Paket Lösungen, von denen ich einige hier nenne und es waere nett wenn noch
mehr Leute ihre pakete hier auch auflisten könnten. Ich gehe davon aus dass
nicht ein einziges darunter ist das auf Grid Elements und nicht auf FLUID
aufbaut.

http://if-20.com/produkte/fluid-template-manager/ - baut auf FLUID auf
http://bootstrap.typo3cms.demo.typo3.org - baut auf FLUID auf
https://fedext.net - baut auf FLUID auf
http://t3bootstrap.de/de/typo3-bootstrap-template/ - baut auf Fluid auf
(sehr zu empfehlen by the way)
http://t3bootstraptv.de/de/typo3-bootstrap-template/ - nutz TemplaVoila -
leider sind die Columns hier nicht logisch zusammengefasst wie beim
Framework for TemplaVoila, aber ansonsten ein template mit dem sich in nur
wenigen Stunden Seiten aufsetzen lassen, die dann vomRedakteur auch selber
kosten guenstig und einfach mit Content gefuellt werden koennen und er kann
selber entscheiden wo er welche FCEs einsetzen will.



Das WICHTIGSTE NO GO Argument fuer Grid Elements ist IMHO jedoch dieses
hier: Was heisst hier Conditional???? Ist eben dieses Conditional der WAHRE
Grund weshalb es seit Monaten / Jahren eine weiterentwicklung zu einem user
friendly TYPO3 das FREE FOR ALL ist und auch bleiben will blockiert?
http://vschart.com/compare/grid-elements-typo3-extension/vs/templavoila
Ein Vergleich der Hinkt denn vieles was hier als nicht moeglich in TV
dargestellt wird ist seit Jahren In TV moeglich ;-) z.B. das Kopieren von
allen moeglichen Elementen / auch Columns auf andere Seiten.


Free to useConditional

Doch was heisst hier "Conditional" - WAS KOSTET GRIDELEMENTS DEN DEVELOPER
bzw. den USER, was sind die Konditionen, wieso steht hier nicht FREE FOR
ALL oder YES wie bei FLUID und TemplaVoila. Was wird hier nicht
ausgesprochen und verursacht eventuel spaeter ein boeses erwachen?

Andi




2013/9/24 JoH asenau <info at cybercraft.de>

> 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 <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 at lists.typo3.org
> http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-**german<http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german>
>


More information about the TYPO3-german mailing list