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