Re: [TYPO3-german] gridelements vs fedext
Hi Joey Dir auch ein schoenes Wochenende. du verstehst das schon richtig. Die Power des Frameworks for TemplaVoila ist eben dass man die Themes des TVfW 1 und 2 beliebig austauschen kann und dass die Content Elemente danach immer wieder in die richtige position springen - es sei denn man waehlt anstatt 3 nur 2 Spalten dann natuerlich landen die Elemente aus der dritten Spalte in Non Used Elements Tab. Hierin ist TVfW bisher immer noch erste Sahne da es bisher keines der auch auf TV aufbauenden Webseiten schafft die Elemente richtig umzuschichten in neue Ansichten. Das war auch das Problem damals als das WEC Paket rauskam und dank GIDEON der damals seine TABS entwickelt hatte wurde eben solange gefeilt bis das alles austauschbar war - siehe die YUI templates im TER die wir damals hochstellten. Wir gaben dann jedoch YUI zugunsten zum FWfTV auf. Da THEMES viele der TVfW ideen (wenn nicht inzwischen fast alle) in fluid umgesetzen kann ist es der ideale Nachfolger fuer Nutzer freundliche TYPO3 Pakete. Ich wuensche Euch sehr viel Erfolg auf der T3Con in Stuttgart und as dieser Patch endlich in den CORE kommt! Wie gesagt die Austauschbarkeit der kompletten Themes so dass der bereits vorhandene Content in den richtigen positionen wieder angezeigt wird auch wenn man Spalten Enstellungen voein spaltig auf 3 spaltig mit Maincontent links aussen umstellt ist das eigentliche alleinstellungs Merkmal das man auch bei anderen CMS bisher nicht findet! Themes und erst Recht Distributionen die dann THEMES als Basis nutzen sind dan die Treibende Kraft fuer den Massen Markt der CMS interessierten SMEs, NGOs. Baut man dann noch die moeglichkeit ein dass man jedem CE eine klasse beiordnen kann so dass man zB auch die ICONS etc einfach anzeigen kann dann hat man zusammen mit einem ALOHA Editor der auch im Frontend Funktioineren sollte eine SOLIDE Basis die an DRUPAL 8 vorbeizieht. Dann fehlt nur noch ein Responsive Backend ;-) Andi Sent from my iPad On 27 ก.ย. 2556, at 16:11, JoH asenau i...@cybercraft.de wrote: Moin moin. Schön, dass wir auch noch Off-Off-Topic weiterkommen ;-) Es stand die Frage im Raum, warum es so wenig Packages für Gridelements gibt, bzw. Extensions, die darauf beruhen. Den Punkt habe ich nicht wirklich verstanden, denn für mich ist GE eine Erweiterung, die es mir erlaubt, Erweiterungen einzusparen. Das sehe ich im Prinzip ähnlich, ich meine aber zu verstehen, was andreas meinte. Claus Due hat für seine Fedext-Suite einiges an Extensions erzeugt, die z.B. Twitter-Bootstrap mit Fedext verheiraten und dabei sowas wie Best Practice Beispiel sein können. Basierend darauf hat z.B. Fabien die aktuell auf typo3.org verfügbare Bootstrap-Distribtion gebaut. Das Problem damit besteht lediglich in der Datenhaltung, die wie schon bei TV auf XML in Datenbankfeldern setzt. Von daher ist das empfehlenswert als Beispiel für Fedext aber eben nicht als Basis für einen universellen Theming-Ansatz, weil wir damit sowohl kleine bis mittlere als auch große Systeme bedienen müssen. Ich habe seit meinem Erstkontakt zu GE nie nach Erweiterungen dafür gesucht, muss zu meiner Schande gestehen, mich noch nicht einmal mit Themes beschäftigt zu haben (wahrscheinlich entwickle ich seit einem Jahr sinnlos etwas Vergleichbares). Warum? Weil es eben geht, mit GE und wahrscheinlich ebenso gut mit FED/Flux. Das, was Du da auf die Beine gestellt ist vermutlich alles andere als sinnlos, weswegen ich Dich ja auch zum nächsten Sprint-Wochenende eingeladen habe. Kays Themes-Extension setzt auf einer anderen Ebene an, die es ermöglichen wird, Deine Arbeit in erweiterter Form als Theme-Base-Package zu nutzen und mit passenden Bildern, CSS und JS, sowie zusätzlichen Struktur- und Inhaltselementen zu versehen, die dann das eigentliche Theme bilden. Zur umgangssprachlichen Erklärung zum winzigen Bisschen, an dem es derzeit noch zwischen Core und GE mangelt. Es geht um den uralten Wunsch, BE-Layouts installierbar zu gestalten. Das ist etwas Seitenrelevantes, und hat eigentlich mit GE rein gar nix zu tun. Die einzige Verbindung ist die Tatsache, dass GE diese Funktion schon immer beinhaltet. Mit 6.1 kann man die Dinger bereits ins Dateisystem packen, und zusammen mit der Hoffnung, dass das bald noch einfacher wird, kann ich damit derzeit problemlos leben. Genau dieses Bisschen wäre das Sahnehäubchen für Themes, obwohl es für einen Großteil der Nutzer rein theoretisch auch ohne diese Funktionalität gehen würde. Probleme gibt es beim rein Datensatz-basierten Ansatz lediglich dann, wenn man nacheinander mehrere Themes installieren wollen würde, die bei gleicher Layout-ID verschiedene Strukturen liefern würden. Auf der anderen Seite würden existierende UIDs auf grund von Autoinrecment dazu führen, dass importierte Datensätze andere IDs bekommen als sie im dazugehörigen TypoScript verwendet werden. Um diese möglichen Konflikte zu vermeiden
Re: [TYPO3-german] gridelements vs fedext
Dir auch ein schoenes Wochenende. du verstehst das schon richtig. Die Power des Frameworks for TemplaVoila ist eben dass man die Themes des TVfW 1 und 2 beliebig austauschen kann und dass die Content Elemente danach immer wieder in die richtige position springen - es sei denn man waehlt anstatt 3 nur 2 Spalten dann natuerlich landen die Elemente aus der dritten Spalte in Non Used Elements Tab. Hierin ist TVfW bisher immer noch erste Sahne da es bisher keines der auch auf TV aufbauenden Webseiten schafft die Elemente richtig umzuschichten in neue Ansichten. Das war auch das Problem damals als das WEC Paket rauskam und dank GIDEON der damals seine TABS entwickelt hatte wurde eben solange gefeilt bis das alles austauschbar war - siehe die YUI templates im TER die wir damals hochstellten. Wir gaben dann jedoch YUI zugunsten zum FWfTV auf. Da THEMES viele der TVfW ideen (wenn nicht inzwischen fast alle) in fluid umgesetzen kann ist es der ideale Nachfolger fuer Nutzer freundliche TYPO3 Pakete. Das Prinzip kannst Du mit normalisierten Daten natürlich viel einfacher umsetzen als mit TV, weil die Spalten anhand einer ID eindeutig zugewiesen werden können. Wobei meiner Meinung nach das Ziel sein sollte, dass der Container sich bei einem Theme-Wechsel überhaupt nicht ändern muss, solange die Basis des Themes (z.B. Twitter-Bootstrap) dieselbe bleibt. Sollte die Basis eine andere sein und zudem noch grundlegend andere Strukturen erfordern, wäre es dennoch sinnvoll, so weit wie möglich ohne komplettes Nachjustieren der Inhalte auszukommen. Das hatte ich bisher immer so auf dem Schirm, weswegen wir auch unbedingt von den reinen XML-Strukturen weg müssen. Gridelements gehen aber schon heute noch einen Schritt weiter: Wenn Du einen Container nimmst und dessen Layout änderst, werden Inhalte von identischen Spalten-IDs beibehalten, während die anderen in Spalte -2 wandern. Diese Spalte kann man dann z.B. in einem Seiten-Backend-Layout anlegen und wenn man möchte, kann sie auch unused elements heissen. Der eigentliche Trick liegt aber im Feld backupColPos, das wir in tt_content einbauen. Dort befindet sich nämlich nach einem solchen Layout-Wechsel die vorherige Spalten-Nummer, so dass Du bei einem fälschlich zugewiesenen Layout sofort wieder das ursprüngliche auswählen kannst, ohne die Struktur der Daten zu verlieren. Voraussetzung ist, dass die einzelnen Layouts so weit wie möglich mit identischen Spaltennummern arbeiten, was bei Themes aber ohnehin so geplant ist. Damit bekommen wir zwar nicht alle Redakteurs-Fehler in den Griff, aber es wird weitaus schwieriger, die Struktur zu zerstören, als das bei reinem XML der Fall gewesen wäre. Kannst ja mal damit experimentieren :-) Schönen Abend 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
Re: [TYPO3-german] gridelements vs fedext
Hey, Ihr Lieben, kommt doch bitte mal wieder runter. Klar sind bei TYPO3 schwere Fehler gemacht worden - und dies gar über einen recht langen Zeitraum und begleitet auch von meinem Gemecker. Trotz alledem - das ist zumindest mein Gefühl - hat es vor nicht allzu langer Zeit einen befreienden Knall gegeben, und Entscheidungen wurden wieder deutlich rationaler. Heute (ich spreche von 6.1, und Teilen aus 6.2, die ich mir cherry-picke) ist die Basis sehr gut geraten. Man hat die Wahl der Waffen, Fluid oder semi-klassisch, und auch der Extension Baukasten wird wieder kompletter. Wenn Manche zu Drupal oder xyz wechseln, so werden sie für sich Gründe dafür gefunden haben. Ich empfinde mich zu alt für einen kompletten Systemwechsel - und sehe auch keine Notwendigkeit mehr dafür. Um den Schwenk zurück zum Thema kriegen: Es stand die Frage im Raum, warum es so wenig Packages für Gridelements gibt, bzw. Extensions, die darauf beruhen. Den Punkt habe ich nicht wirklich verstanden, denn für mich ist GE eine Erweiterung, die es mir erlaubt, Erweiterungen einzusparen. Ich habe seit meinem Erstkontakt zu GE nie nach Erweiterungen dafür gesucht, muss zu meiner Schande gestehen, mich noch nicht einmal mit Themes beschäftigt zu haben (wahrscheinlich entwickle ich seit einem Jahr sinnlos etwas Vergleichbares). Warum? Weil es eben geht, mit GE und wahrscheinlich ebenso gut mit FED/Flux. Zur umgangssprachlichen Erklärung zum winzigen Bisschen, an dem es derzeit noch zwischen Core und GE mangelt. Es geht um den uralten Wunsch, BE-Layouts installierbar zu gestalten. Das ist etwas Seitenrelevantes, und hat eigentlich mit GE rein gar nix zu tun. Die einzige Verbindung ist die Tatsache, dass GE diese Funktion schon immer beinhaltet. Mit 6.1 kann man die Dinger bereits ins Dateisystem packen, und zusammen mit der Hoffnung, dass das bald noch einfacher wird, kann ich damit derzeit problemlos leben. Für mich ist das TYPO3 Glas heute nicht mehr halbleer, sondern mindestens wieder halbvoll, und mit einigen gemeinsamen Bemühungen sollten wir locker nachschenken können. Findet zumindest der Thomas ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] gridelements vs fedext
Hi Joey Fakt ist, dass wir sehr schnell zu sehr guten Ergebnissen bei THEMES kamen bis dass der beschluss gefasst wurde, dass man Gridelements integriert!. Seiher verzoegert sich alles erheblich, da man auf Patches warten muss! Viel besser waere es diese Gridelements in ein spaeteres release in TYPO3 und ggf auch in THEMES zu integrieren. Schau dir doch einfach einmal die realitaet an - FAKT ist das es kein brauchbares Beispiel Paket mit Gridelements gibt, inzwischen jedoch zig Pakete mit Fluid verwirklicht wurden und leider all diese Pakete inzwischen ihren eigenen Weg gehen. Genau das sollte mit THEMES ja vermieden werden, doch dazu muss es auch brauchbar an den Star gehen koennen und nicht auf irgend welche Bestandteile warten die im Grunde denen die bisher Templa Voila eingestetz hatten und damit MEHR als zufrieden waren absolut garnichts an neuigkeiten bringt. Du siehst das voellig richtig das die BREMSE BEIM CORE TEAM liegt - wie sie ja schon bereits bei zig anderen aehnlichen Beispielen dort lag - siehe Multi Shop! und nicht zuletzt auch TemplaVoila. Danke das wir hier einer Meinung sind! Deine Bemerkungen bezüglich RANT Modus kannst du dir uebrigens sparen! Keiner wuerde auch nur ein Wort darueber verlieren wenn Gridelements bereits laufen wuerde und man erfolgreich auch pakages haette an denen man sehen kann was fuer vorteile es wirklich bringt. Im Moment ist all dieses Warten nur schaedlich fuer TYPO3 und die Agenturen die TYPO3 einsetzen. GUTEN Gewissens kann man heute leider keinem mehr TYPO3 empfehlen - der Kunde braucht hierzu nur einmal auf die Mailingliste zu schauen. Auch heute kam wieder ein Kunde der auf KEINEN Fall wieder TYPO3 wollte (er war vorher nicht bei uns! by the way) Er will nun eine Drupal seite weshalb er uns kontaktierte, da ja auch die Daten der alten Seite nach Drupal sollen. Drag und Drop kann man mit dem Framework for TemplaVoila seit Jahren schon. Zu deinem Punkt 5!!! Bisher hat KEINER unserer Kunden TemplaVoila als einen Nachteil angesehen, ganz im Gegenteil und die meisten dieser Kunden steigen nunmehr auf andere CMS um weil man TemplaVoila den Garaus gemacht hat und weil es bis dato noch keine wirklich verghleichsweise Alternative gibt wie das Framework for TemplaViola - Genau das wollten Kay und ich mit THEMES ändern, doch hierzu muss es endlich an den Start kommen und nicht noch weiter verzoegert werden. Bereits jetzt ist abzusehen das die Kunden Gridelements wiederum verschmaehen werden und sich ueber FLUID freuen werden und die neue Diskussion die wir eigentlich vermeiden wiollten naemlich FLUID - Gridelements ist ja bereits seit Monaten nun schon im Gange! Und es ist nur eine Frage der Zeit bis dass man wieder zwei gruppen hat, naemlich so wie bei TV und bei Traditionell. USABILITY sollte das Augenmerk sein und zwar fuer den EDITOR denjenigen der die Seite Kauft!! Un d Gridelements bringt hier leider keine grossen Vorteile, Jedoch Fluid tut es. Also wenn schon Gridelements dann bitte nichtnoch weitere Verzögerungen von wem auch immer und stelle endlich eihnmal klar was Gridelements KOSTET - auch das ist misst wenn da sio ein Mist steht! sorry! Andi 2013/9/25 JoH asenau i...@cybercraft.de Am 25.09.2013 13:22, schrieb Cedric Ziel: Hallo Joey; Danke für deine Erläuterungen. Ich hätte mich über einen darüberhinausgehenden Dialog gefreut, dieser kann anscheinend leider nicht hier stattfinden, da unsachlich und vor Allem OT herein gegrätscht wird. Andreas ist halt gerade wieder im Rant-Modus :-) Ich hoffe, dass meine Antwort das relativieren kann, falls nicht, fände ich das schade. Wir können hier aber gern trotzdem schauen, wie wir zu Ergebnissen kommen, die für alle hilfreich sind, zumal Gridelements und Fluidcontent problemlos in derselben TYPO3-Instanz nebeneinander genutzt werden können. Frohes Schaffen! 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-**germanhttp://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
Re: [TYPO3-german] gridelements vs fedext
Lieber Andreas Es mag richtig sein, dass es kein Beispiel-Paket mit Gridelements für TYPO3 gibt. Ich weiss es nicht. Es ist aber auch sicherlich so, dass nicht jeder TYPO3-Integrator und jede Agentur das Bedürfnis hat, eine TYPO3-Instanz auf Basis eines Beispiel-Pakets aufzubauen oder Themens zu benutzen. Daraus, dass Gridelements in Zusammenhang mit Themenes Probleme macht, den Schluss zu ziehen, dass Gridelements weniger usable ist für eine TYPO3-Website als andere Lösungen, ist daher nicht zutreffend. Ich setze Gridelements in einigen Projekten ein, in denen ich mit Backend Layouts und FLUIDTEMPLATE arbeite, aber einige Spezial-Container (Multi Content, Accordion etc.) benötige. Möglicherweise wären die anderen Lösungen dafür genauso geeignet, aber ich bin mit Grid Elements zufrieden. Das Bedürfnis meiner Kunden ist in der Regel eine Website oder eine Webanwendung, die einen Katalog an Kriterien erfüllt und für den Redakteur nachher gut bedienbar ist. Ich hatte bisher keine Mühe, diese Kriterien mit TYPO3 zu erfüllen und den Kunden guten Gewissens ein Angebot zu machen. Ich habe auch noch nie Kunden gehabt, die informiert waren, dass das Core-Team (angeblich) TemplaVoila den Garaus machen will. Meine Kunden wissen auch nicht, dass sie mit Gridelements arbeiten. Sie wissen, dass sie mit TYPO3 arbeiten, das von uns nach bestem Wissen so integriert wurde, dass sie ihre Arbeit komfortabel machen können und ihre Anforderungen erfüllt werden. Zu den Kosten von gridelements kann ich nur sagen, dass die Extension mit vollem Funktionsumfang im TER verfügbar ist. Da du ja schon länger in der Community bist (mindestens gemessen an der Länge deiner Beiträge), dürftest du wissen, was das bedeutet. Man konnte aber das Crowdfunding unterstützen und bezahlte einen kleinen Anteil aus den Steuern (Association-Mitgliedschaft). Beste Grüsse, Lorenz Am 26.09.2013 13:29, schrieb Andreas Becker: ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] gridelements vs fedext
Danke Lorenz fuer deine persoenlichen Infos. Mit TemplaVoila war TYPO3 unschlagbar in Punktu usability. Viele kamen und fragten speziell auch danach. Doch toleivs Statement hinterlies grosse Sorgen bei vielen. Mit Themes sollte dem abgeholfen werden und kay kam auch super voran. Doch dann kam dieser Beschluss Gridelements zu integrieren und seither liegt alles brach - kein wirklicher Fortschritt seit Monaten. Den Grund hierfuer hat Joey sehr treffend benannt. CORE Patch nicht integriert Waehre dies schon laengst geschehen und haette Joey oder du oder ein anderer der mit Grodelements arbeitet mal ein Beispiel Paket mit GridElements aufgestellt das wirklich begeistert und Lust und Laune auf mehr macht so wie es damals Claus Due tat, dann gaebe es diese diskussion wohl nicht hier. Fakt ist nun einmal dass sich JEDER im nu ohne grosse Programmierlenntnisse in ein Framework for Templavoila oder in ein anderes TV oder FLUId Paket einarbeiten kann. Einzige ausnahme bilden hier die Pakete die auf einer Frischen TYPO3 Installation beruhen denn da landen die tester erst einmal auf error pages!!! Lade dir einfach einmal die restaurant distribution von drupal runter oder eine andere .. und du wirst schnell sehen das das nur so flutscht und sofort kann man damit arbeiten. Genau so etwas fehlt TYPO3 seit es das WEC Paket nicht mehr in aktueller Version gibt. Themes sollte hier weiterhelfen. Doch Pustekuchen. Die idee gridelements zu integrieren um ALLE Stroemungen zu integrieren scheiterte bisher dank CORE TEAM. es liegt nicht an Joey!!! Es ist diese Blockade Politik die im Grunde vielem dem Garaus macht und gute Ideen erheblich verzoegert oder gar vernichtet. lese dir Toleiivs Statement durch, oder rede einmal mit Mark Stephenson (Leiter WEC) etc mit Leuten die sehr viel fuer TYPO3 an user friendliness und promotion mit einbrachten. Der Patch fuer Multishop brauchte 8 Monate und bei dem fuer Grid Elements wird es wohl auch so sein wenn das so weitergeht! Ziel von Themes war u. a auch energien zu buendeln. Basis si d die Ideen aus dem Framework for Templavoila und Kays Sitemanager. Recht schnell entstand daraus eine regelrechte Suite mit super features die ebenso schnell in einem Vagrant umgestzt wurden den jeder testen konnte. doch dieser Core Patch blokiert nach wie vor die weiterentwicklung. UND er ist notwendig da GridElements integriert werden soll. Alle die inzwischen eigene FLUID pakete herausgebracht haben wie es ja inzwischen auch auf TYPO3.org sebst promoted wird!!! sind happy OHNE Grid Elements und sie funktionieren gut und sehen auch ansprechend aus. Das bootstrap intro package duerfte inzwischen standard vieler Seiten die auf 6.+ basieren. Nicht einmal hier benoetigt man Grid Elements um user freundliche Seiten zu entwickeln. Kurzum keiner hat was gegen Grid Elements als Extension und so sollte es auch weiterhin bleiben. im Core hat das nix zu suchen es sei denn dieser patch ermoeglicht es das Themes integriert wird Mit Grid Elements. Das macht wirklich sinn! Schau einfach einmal ueber den T3 tellerrand was sich auf dem CMS markt tut! drupal setzt auf ein bewaertes framework TYPO3 auf ein unbekanntes und das bisher nur in TYPO3 im Grunde von sich reden macht und das alte 6.+ hat noch nicht einmal ein stabiles Framework! Drupal setzt Twig ein das von vielen SYMPHONY Applicationen beteits genutzt wird und Fluid sehr aehnlich ist TYPO3 weiss derweilen immer noch nicht wann Gridelements und Fluid wirklich stabil laufen. In Drupal hat man frontend inline editing was bei TYPO3 ne Fehlanzeige ist. Gibts nicht. in Drupal8 ist sogar das Backend responsiv. Auch hier fehlanzeige bei TYPO3. Bei Drupal kann man inzwischen fuer die Unterschiedlichsten Bereich Diateibutionen odt sogar mit DRUSH in wenigen Minuten samt Demo Content zum Laufen bringen. So was gibt es bei TYPO3 schlichtweg nicht abgesehen von den YAML fuer TV Und das FTM Sowoe das WEC Package. Genau hiet kann Themes ansetzen um Kunden zurueckzugewinnen bzw nicht weitere zu verlieren. doch genau dort geht es nicht weiter wegen diesem Patch. Von inspire to share ist schon lange keine Spur mehr bei TYPO3 zu sehen. Bei Drupal hingegen bringen sich immer mehr namhafte Agenturen mit Diatributionen ein die echt begeistern! Richtig Kunden wollen ein Webseite bei der sie den Content selber pflegen koennen ohne Ein progi zu sein. und genau dort verliert TYPO3 immer mehr Marktanteile an moderne CMS wie eben Drupal, Contao und vorallem an WordPress. Kommt der patch nicht umgehend bis ende der Woche in den Core, dann ist echt zu empfehlen die Zwei bzw nunmehr Dreiklassen TYPO3 Community weiter zu zerstueckeln und eben weiterhin NUR TV oder NUR FLUID oder eben wie zuvor altbakenes traditionelles Temating einzusetzen anstatt zu versuchen diese Stroemungen mit Themea zu buendeln in ein wirklich powerful Templating und Distribution System das sogar Tenant faehig ist!! Klar Kay redet auf T3CON in
Re: [TYPO3-german] gridelements vs fedext
Guten Abend, Andreas :-) Vorab zwei Fragen bezüglich Deiner Erfahrungswerte, bevor wir zu einer Zusammenfassung von Fakten kommen: Wieviele Projekte hast Du selbst bisher mit Gridelements und Fluidcontent umgesetzt, die es Dir realistisch ermöglichen die Usability und Funktionalität von beiden miteinander und mit der von TemplaVoila zu vergleichen? Wieviele Deiner Projekte, inklusive derer, die Du mit TemplaVoila umgesetzt hast, haben dabei eine mindestens fünfstellige Anzahl von Seiten und Inhaltselementen? Fakt ist, dass wir sehr schnell zu sehr guten Ergebnissen bei THEMES kamen bis dass der beschluss gefasst wurde, dass man Gridelements integriert!. Seiher verzoegert sich alles erheblich, da man auf Patches warten muss! Fakt ist, dass die Arbeit an THEMES bisher zum Großteil von Kay Strobach geleistet wurde und Du selbst lediglich ein Theme und Ideen beigesteuert hast. Das WIR ist daher durchaus relativ zu betrachten. Viel besser waere es diese Gridelements in ein spaeteres release in TYPO3 und ggf auch in THEMES zu integrieren. Fakt ist, dass Gridelements weder in den Core noch in Themes integriert wird, es bleibt eine eigenständige Extension. Es wird allerdings so sein, dass Gridelements den strukturellen Part für Themes liefern wird, weil dies auf der technischen Ebene verschiedene Vorteile hat. Diese Vorteile liegen vor allem in der sauberen Normalisierung von Eltern-Kind-Beziehungen, die es ermöglicht weitaus performanter auf Daten zuzugreifen als das mit irgendeiner anderen Lösung möglich ist. Das mag für viele Deiner Kunden irrelevant sein, weil sie keine Datenmengen zu verarbeiten haben, bei denen sich der Performance-Unterschied signifikant bemerkbar machen würde, jedoch muß TYPO3 den Spagat zwischen Kleinst-Anwender und Enterprise-Projekt hinbekommen, weswegen Performance ein absolut relevantes Kriterium ist. Dies gilt selbstverständlich auch für eine Lösung, die den Anspruch erhebt DER Ansatz für TYPO3 Themes zu sein. Schau dir doch einfach einmal die realitaet an - FAKT ist das es kein brauchbares Beispiel Paket mit Gridelements gibt, inzwischen jedoch zig Pakete mit Fluid verwirklicht wurden und leider all diese Pakete inzwischen ihren eigenen Weg gehen. Genau das sollte mit THEMES ja vermieden werden, doch dazu muss es auch brauchbar an den Star gehen koennen und nicht auf irgend welche Bestandteile warten die im Grunde denen die bisher Templa Voila eingestetz hatten und damit MEHR als zufrieden waren absolut garnichts an neuigkeiten bringt. Fakt ist wiederum, dass Themes vor allem auf TYPO3 6.2 LTS ausgelegt wird, weil damit eine sinnvolle Basis für die nächsten 3 bis 4 Jahre geschaffen wird. Da der Release von 6.2.0 stable erst gegen Ende des Jahres geplant ist, besteht daher absolut kein Grund zur Eile, denn wir wollen nicht möglichst schnell irgendeine Lösung liefern, sondern in der dafür nötigen Zeit eine ausgereifte Lösung, die allen Anwendern vom Neueinsteiger bis zum alteingesessenen Profi von Nutzen sein wird. Es gibt viele Neuigkeiten, die Gridelements bereits heute im Vergleich zu TemplaVoila bietet: Drag In von neuen Elementen, Erzeugen von Kopien per Drag Drop, Kopien von Elementen anderer Seiten (ohne die aktuelle Seite zu verlassen), Referenzen auf den kompletten Inhalt einer Seite (am Stück), normalisierte Verknüpfungen zu Kindelementen, automatische Verfügbarkeit sämtlicher Felder des Elternelements beim Rendern der Kinder, einzelne und nach Spalten gruppierte Rohdaten für die Ausgabe mit FLUIDTEMPLATE und zusätzlich in vorgerenderter Form für die Ausgabe mit TEMPLATE. Für Themes wollen wir noch weitere nützliche Features einbauen, weswegen wir beim nächsten Sprint verschiedene Teams (Gridelements, Themes, Core, Anwender) zusammenführen, um einen Konsens hinsichtlich der Roadmap zu erreichen. Du siehst das voellig richtig das die BREMSE BEIM CORE TEAM liegt - wie sie ja schon bereits bei zig anderen aehnlichen Beispielen dort lag - siehe Multi Shop! und nicht zuletzt auch TemplaVoila. Danke das wir hier einer Meinung sind! Deine Bemerkungen bezüglich RANT Modus kannst du dir uebrigens sparen! Keiner wuerde auch nur ein Wort darueber verlieren wenn Gridelements bereits laufen wuerde und man erfolgreich auch pakages haette an denen man sehen kann was fuer vorteile es wirklich bringt. Im Moment ist all dieses Warten nur schaedlich fuer TYPO3 und die Agenturen die TYPO3 einsetzen. GUTEN Gewissens kann man heute leider keinem mehr TYPO3 empfehlen - der Kunde braucht hierzu nur einmal auf die Mailingliste zu schauen. Auch heute kam wieder ein Kunde der auf KEINEN Fall wieder TYPO3 wollte (er war vorher nicht bei uns! by the way) Er will nun eine Drupal seite weshalb er uns kontaktierte, da ja auch die Daten der alten Seite nach Drupal sollen. Genau dieses Gefasel ist es, was ich mit RANT-MODUS meine. Das Core-Team hat einen Haufen Arbeit zu erledigen, die extrem wichtig für das
Re: [TYPO3-german] gridelements vs fedext
Nochmal guten Abend. Einziges Manko das All das BLOCKT ist dieser CORE PATCH. zig leute haben beteits fuer den Patch gevotet! Doch NULL reaktion bisher! Fakt ist: Wir haben ein Agreement mit dem Core-Team, dass es für TSconfig basierte Backend-Layouts für Seiten - und NUR darum geht es, NICHT um Gridelements - keine direkte Core-Funktionalität geben wird. Stattdessen ist ein Dataprovider vorgesehen, mit dem eizelne Extensions unabhängig von der Quelle Backend-Layouts beisteuern können, die vom Core dann zusätzlich zu den eigenen datensatz-basierten Layouts verwendet werden können. - Vorteil: Du kannst neben TSconfig X-beliebige Varianten nutzen, um Deine Backend-Layouts zu erzeugen und in den Core zu injecten. Aktueller Stand ist: Wir haben beim letzten Grid-Sprint den Patch so weit aufgearbeitet, dass er hinsichtlich Performance und Datenstruktur optimal nutzbar wird. Lediglich der eigentliche Dataprovider muss noch eingearbeitet werden, was bis zum Feature-Freeze auch geschehen wird. Jigal hat seine Blockade des ursprünglichen Patches daher zurückgezogen, weil damit sichergestellt ist, dass der Core selbst nur EINE Methode für Backend-Layouts verwendet, nämlich Datensätze. Der Grund für die Entscheidung pro Backend-Layouts und contra Fluidpages ist identisch mit denen, die ich in meinem anderen Post erläutert habe. Also - Ball flach halten - Patch kommt! :-) 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
Re: [TYPO3-german] gridelements vs fedext
Hallo; Vllt sollte man anfügen, das ein Code Review mehr ist, als ein Vote. Ein Vote in Forge ist im Prinzip nur ein Signal. Die Implementierung wird im Review überprüft. Sollte zumindest. Beim besagten Patch kamen auch bei mir berechtigte Zweifel auf, das viele einfach nur den Button gedrückt haben, ohne den Code zu überprüfen. Für Andi hätte ich noch den Vorschlag, ins andere Lager zu wechseln-wenn dort alles besser ist, könntest Du dich dort wohler fühlen. Grüße, Cedric Zitat von JoH asenau i...@cybercraft.de: Nochmal guten Abend. Einziges Manko das All das BLOCKT ist dieser CORE PATCH. zig leute haben beteits fuer den Patch gevotet! Doch NULL reaktion bisher! Fakt ist: Wir haben ein Agreement mit dem Core-Team, dass es für TSconfig basierte Backend-Layouts für Seiten - und NUR darum geht es, NICHT um Gridelements - keine direkte Core-Funktionalität geben wird. Stattdessen ist ein Dataprovider vorgesehen, mit dem eizelne Extensions unabhängig von der Quelle Backend-Layouts beisteuern können, die vom Core dann zusätzlich zu den eigenen datensatz-basierten Layouts verwendet werden können. - Vorteil: Du kannst neben TSconfig X-beliebige Varianten nutzen, um Deine Backend-Layouts zu erzeugen und in den Core zu injecten. Aktueller Stand ist: Wir haben beim letzten Grid-Sprint den Patch so weit aufgearbeitet, dass er hinsichtlich Performance und Datenstruktur optimal nutzbar wird. Lediglich der eigentliche Dataprovider muss noch eingearbeitet werden, was bis zum Feature-Freeze auch geschehen wird. Jigal hat seine Blockade des ursprünglichen Patches daher zurückgezogen, weil damit sichergestellt ist, dass der Core selbst nur EINE Methode für Backend-Layouts verwendet, nämlich Datensätze. Der Grund für die Entscheidung pro Backend-Layouts und contra Fluidpages ist identisch mit denen, die ich in meinem anderen Post erläutert habe. Also - Ball flach halten - Patch kommt! :-) 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.orghttp://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german -- Cedric Volker Ziel Internetdienstleistungen EDV Robert-Koch-Str. 40 06110 Halle (Saale) Telefon: +49 (0) 345 / 213 79 532 Telefax: +49 (0) 1805 / 388 37 9447 Mobil: +49 (0) 151 / 253 44 284 Mail: i...@cedric-ziel.com Web: http://www.cedric-ziel.com XING: http://www.xing.com/profile/Cedric_Ziel ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] gridelements vs fedext
Cedric Lese einfach was Joey immer an seine Mails anfuegt! ich weiss nicht seit wann du mit TYPO3 unterwegs bist aber das scheint noch nicht so lange zu sein! Es geht hier nicht darum in irgend welche Lager zu wechseln, ganz im Gegenteil geht es darum die fuer TYPO3 zu gewinnen bzw. Zurueck zugewinnen. Oeffne einfach einmal deine Augen ;-) TYPO3 war einst ein sehr stabiles, sehr flexibles und auch nutzerfreundliches System, dank Pagetree wuerde ich mal heute sagen. Es wurde noch besser und hat einen riesen Sprung gemacht als TemplaVoila verstaendlich und stabil gemacht wurde nach Robert Lemke durch Dmitry, und bis heute gibt es nichts vergleichbares. Joey lese auch du deineb Spruch bitte selber einmal und fliege ggf mal ueber die unzaehligen Skype Protokolle seit Jahren zwischen mir und Kay. Es ist schlichtweg unverstaendlich und marketing kontraproduktiv was TYPO3 sich hier leistet seit Jahren. Und mit THEMES scheint es nun leider auch so weiterzugehen, schade! Mal ehrlich wer braucht Seiten wie du sie hier beschreibst? Wieviele Developer aus der TYPO3 gemeinde hatten jemals ein Projekt mit diesen zahlen? Sollen solche Projekte die Zukunft fuer TYPO3 sein? Aber um dich zu beruhigen, wir arbeiteten in der Vergangenheit auch an Projekten mit sehr hoher vierstelliger Seitenzahl mit funfstelligen Assets und CEs. Doch nicht alle waren hierbei mit Templavoila gemacht. Der Grund hierfuer lag jedoch weniger in TV selbst, als das der urspruengliche Entwickler sich damals mit TV nicht auskannte und sich dort auch nicht einarbeiten wollte. Sprich wir hatten klare Vorgaben vom Headquarter. In einem anderen aehnlichen Projekt das zudem noch einen hohen reistelligen Zahl an Redakteuren hatten war die Vorgabe genau entgegengesetz. auch hier der Grund ganz simple dass derjenige der Verantwortlich war die unflexibilitaet vom standard Templating damals nicht wollte und TV einfach Geil fand und das obwohl es das TV Framework damals noch in Vesion 1 war. Die erste Seite nutzt nach wie vor TYPO3 und Standard Templating und die zweite ist inzwischen WordPress. Dies sind nur zwei von mehreren Beispielen, aber die Hauptzahl der Projekte und Anfragen betrifft Seiten im unteren dreistelligen Bereich. dies duerfte so auch die Realitaet der meisten TYPO3 Projekten sein die von TYPO3 Developern und Genturen bearbeitet werden. --- Joey, du schreibst immer wieder mal was ueber die Vorzuege von Grid Elements aber wie waere es diese auch endlich einmal zu zeigen, so wie es Claus mit Fedext machte? Wie ich schon oben Cedric schrieb geht es gerade nicht darum Lager zu wechseln, sondern vielmehr darum schon laengst verlorenen Boden wieder gut zu machen fuer TYPO3. Dies wird TYPO3 jedoch nicht gelingen mit einem Paket fuer die oberen 1000 der Megaseiten Von denen sich Typo3 hofft das ein oder andere Prozent vom Kuchen abzuschneiden. Vielmehr waere es ein Gewinn fuer alle wenn besonders auch die kleinen Projekte oder auch viele NGO Projekte / Schulprojekte / Multidomain Projekte etc pp wieder ein Sustem haetten dass wieder freude macht und begeistert wie damals bei 3.6.1. --- Bezueglich Rant nur noch eines. Er bewegt! Der Patch beim Multishop wurde nach dem was du Rant nennst umgehend bearbeitet und als gut reviewed! Ich hoffe es kann damit nun beim Multishop weitergehen und er kann Boden gegenueber Drupal Commerce etc wieder gut machen. auf geht's Bas. All das was du hier als Rant bezeichnet gaebe es nicht wenn es laufen wuerde und man nicht seit Monaten quasi still steht bei Themes nach der wirklich gelungenen ersten Vagrant Praesentation. Das von dir Beschriebene ECO System sehe ich bei TYPO3 jedoch noch lange nicht. Fuer ein ECO System das seinen Namen auch wirklich verdient wie das z.B Drupal ECO System, bedarf es weit mehr als Themes, Gridelements bzw Code ansich. Hier bei Drupal wird inspire to share wahrhaftig ausgelebt. Es gab, und gibt es sicher noch, ein sehr gutes Video von Kaspar, wo er erklaert wieso er TYPO3 Open Source machte und wieso der Backend Login Joh316 heisst (nach wie vor) 90% von dem was er damals sagte scheint seit seiner Abdankung als Koenig leider verloren gegangen zu sein und EGOs uebernahmeb die Kontrolle. Wir warten hier nun mal ab was das Resultat der T3Con. In der Regel sieht nach solchen TYPO3 events eh alles anders aus ( siehe Tolleiivs Statement ) siehe TYPO3 reorg ( wo auf einmal Matthias Schreibercnicht mehr weitermahte und 3 sich nicht auf eine Fuehrung einigen konnten) etc. Wir hoffen fuer TYPO3 das Kays Praesentation super ankommt und grosse Zustimmung findet und vor allem mehr Support von Dingen wie durch diesen Core Patch der laengst ueberfaellig ist. Andi Sent from my iPad On 26 ก.ย. 2556, at 23:41, Cedric Ziel ced...@cedric-ziel.com wrote: Hallo; Vllt sollte man anfügen, das ein Code Review mehr ist, als ein Vote. Ein Vote in Forge ist im Prinzip nur ein Signal. Die Implementierung wird im Review
Re: [TYPO3-german] gridelements vs fedext
Ich möchte gar nicht auf deine Punkte eingehen, habe aber noch zwei Dinge, die mir generell unter den Nägeln brennen: Wenn dir TemplaVoila am Herzen liegt, dann halte es am Leben, indem Du eine Initiative ins Leben rufst, die genau das tut. Das ist der Geist von OpenSource. - Nicht das Erwarten von Leistungen von jemand anderem. Genauso, wie Du es postuliert hast. Genau so verhält es sich mit den anderen Teilprojekten-Wie Joey dir bereits vorgeschlagen hat, darfst Du dich gerne an jeder Ecke einbringen und das Projekt/die Projekte voran bringen. Es ist irrelevant für den Gesprächskern, wie lange Ich nun mit TYPO3 arbeite. Es ist für mich allerdings relevant, das es für mich und die Bedürfnisse meiner Kunden, unabhängig von der Größe des Projektes seit einigen Jahren nach wie vor das System der Wahl ist. Ich fühle mich wohl in Extbase-und Fluid ist für mich im Gegensatz zu dir nicht nur ein BuzzWord, sondern ein praktisches und mächtiges Instrument. Ich bedanke mich von Herzen für deine Ratschläge.-Ohne diese hätte ich vermutlich niemals erfahren, das man ein Zeit-Ticket lösen muss, um sich hier einbringen zu dürfen. In diesem Sinne wünsche ich dir noch einen schönen Abend; Cedric ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] gridelements vs fedext
Hallo Martin, Bitte schaue dir für einen wirklich schnellen Einstieg mit fluidcontent/flux das Bootstrap Package an. Du findest dies entweder unter get.typo3.org/bootstrap in klassischer Variante, oder auf Github unter https://github.com/Ecodev/bootstrap_package mit ein paar mehr Kniffen. Es kann nicht schaden, dort die Extension Speciality einmal zu durchforsten. Fabien Udriot hat gute Arbeit mit dem Paket geleistet und viele Best-Practices angewandt. Des Weiteren ist im selben Paket bereits unsere fluidcontent_bootstrap untergebracht, die anhand der Bootstrap Elemente sehr gut zeigt, was möglich ist. Solltest Du Fragen haben, so würde ich dich zuerst an den IRC channel #typo3 auf Freenode verweisen. Weitere Hinweise findest Du auf fedext.net, wo die Unabhängig immer die ViewHelper Referenz zur Verfügung steht. Es bewegt sich einiges, daher solltest Du im Zweifelsfall auch die Projekte auf GitHub bzgl bekannter Fehler checken: https://github.com/FluidTYPO3 Wie Jo bereits gesagt hat-die beiden Erweiterungen schließen sich nicht gegenseitig aus. gridelements ist für Strukturelemente sicherlich einen sehr genauen Blick wert; mir fehlt zu einer Empfehlung die Erfahrung damit. Fluidcontent kann zwar auch Strukturelemente abbilden, dennoch macht es außerhalb von FCE's sicherlich Sinn, gridelements mit seiner Normalisierung zu verwenden, um Struktur einzubringen. Viele Grüße, Cedric ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] gridelements vs fedext
Was mich persönlich stört: Von den Entwicklern beider Extensions gibt es wenige Beispiele, die man sofort umsetzen kann. Bei gridelements muß man Unterstützser sein, um an brauchbare Beispiele zu kommen. Auf der Seite von fedext gibt es zwar das Beispiel als fertige Seite, aber auch wenige Codeschnipsel dazu! Schau mal ins Manual (als PDF in der Extension), da sind eigentlich alle grundlegenden Beispiele drin :-) Lediglich der Zugang zum Extended Manual hängt von einem Mindestsupport ab, den Du jederzeit über den Kauf eines T-Shirts erledigen kannst. Die Strukturen kannst Du wie schon bei den Backend-Layouts im Core mit Hilfe eines Wizards erzeugen - das sollte also kein Problem sein. Für Fortgeschrittene geht das Ganze auch über TSconfig, wozu es eine schöne Anleitung von Berit gibt: http://www.networkteam.com/blog/post/gridelements-professionell-nutzen.html Die Ausgabe erfolgt im ersten Schritt ohnehin über TypoScript, wofür es gerade von mir, aber auch von vielen anderen einen Haufen Beispiele unabhängig von Gridelements kostenlos im Netz gibt. Eines speziell für Gridelements ist auch gleich bei Berits Beispiel für die TSconfig-Variante dabei. Du bist damit im Prinzip völlig frei bei der Auswahl Deiner Templating Methode, weil Du entweder reines TypoScript nehmen, oder über cObject = TEMPLATE mit HTML bzw. über cObject = FLUIDTEMPLATE mit Fluid arbeiten kannst. Die verfügbaren Felder und zusätzlichen Parameter sind allesamt im Manual aufgeführt und die zusätzlichen Parameter liegen außerdem in der setup.txt als Default-Setup mit Kommentaren. Für den Einstieg sollte das reichen. Falls Du Fragen hast, poste sie einfach hier oder in typo3.english. In der Regel werden die kurzfristig beantwortet. Viel Spass beim Experimentieren :-) 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
Re: [TYPO3-german] gridelements vs fedext
Cedric Ziel schrieb: Hallo; . Für Andi hätte ich noch den Vorschlag, ins andere Lager zu wechseln-wenn dort alles besser ist, könntest Du dich dort wohler fühlen. Grüße, Cedric Hallo Cedric und all die Anderen, bezugnehmend auf den Tip dort oben, es sind bereits viel zu viele ins andere Lager bzw. in adere Lager abgewandert, - fällt das niemandem auf. Sicher geht Andi hart zur Sache, nur: 1. muss das erlaubt sein, ohne gleich diffamiert und abgeschmettert zu werden 2. mit ein wenig Überzeichnung kommt schnell der Kern der Aussage hervor. Macht ihr aber so weiter, verbleiben noch eine handvoll hartgesottener guter und fleißiger und motivierter Denker und Programmierer. Doch das wird nicht mehr reichen, um TYPO3 bei der geplanten Komplexität einer breiten Community schmackhaft zu machen. Die meisten alten von vor 10 Jahren haben sich bereits abewandt. Mir ist völlig wurscht, ob Fluid oder gridelements oder fedext oder sonstwas unter der Haube werkelt, Joh hatte das bereits so formuliert. Es muß aber endlich funktionieren. Und unsere Geduld wird auf eine viel zu lange Probe gestellt. -- mit freundlichen Grüßen Dipl.Ing.Gert Redlich ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] gridelements vs fedext
Mir ist völlig wurscht, ob Fluid oder gridelements oder fedext oder sonstwas unter der Haube werkelt, Joh hatte das bereits so formuliert. Es muß aber endlich funktionieren. Und unsere Geduld wird auf eine viel zu lange Probe gestellt. Dann hätte ich da einen Job für Dich: https://review.typo3.org/#/c/11804/ Da fehlt noch der Dataprovider - Jigal hat ja bereits ein Beispiel geliefert, wie das schön zu lösen wäre: https://github.com/ohader/mapping Bau den doch grad mal ein - dann geht's auch schneller weiter mit Themes und Backend Layouts bzw. Gridelements :-) Frohes Schaffen 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
Re: [TYPO3-german] gridelements vs fedext
Hallo, TemplaVoila ist nicht tot und nach diesem Post von Tolliev zu urteilen, wird es auch für 6.2 eine Version geben: http://blog.tolleiv.de/2013/06/templavoila-followup/ Das heißt, TemplaVoila wird es noch ca. 4-5 Jahre in dieser Form geben. TV wird von Tolliev aber nicht mehr weiter entwickelt, das ist seine Entscheidung, und die ist zu respektieren. Wenn es tatsächlich viele Agenturen gibt, für die TemplaVoila wichtig und unverzichtbar ist, dann schlage ich vor, diese Agenturen wenden sich an Tolliev und arbeiten entweder mit ihm an der Weiterentwicklung von TemplaVoila, oder übernehmen die Extension von ihm und pflegen sie weiter. Das ist der übliche OpenSource-Weg. Ob eine Extension eingestellt oder weiter entwickelt wird, liegt niemals an oder bei den Core-Entwicklern oder in der Verantwortung der Community als Ganzes, sondern das liegt ausschließlich bei den Leuten, die eine Extension einsetzen wollen und die bereit sind, diese weiter zu entwickeln. Wer mangels Programmierkenntnissen nicht mit programmieren kann, kann sich anders einbringen, z. B. über Organisation, Dokumentation oder über Sponsoring. Wie gut letzteres funktionieren kann, zeigt die Entwicklung von Gridelements. Ich habe gerne mit TemplaVoila gearbeitet, und freue mich, dass es die Extension für 6.2 geben wird, und ich so eine Reihe von alten Projekten noch etliche Jahre weiterführen kann, ohne sie komplett zu überarbeiten. Ich werde TV zwar nicht mehr für neue Projekte einsetzen, da es mittlerweile Alternativen gibt, aber ich würde mich deshalb als Sponsor an Bugfixing und Maintenance beteiligen. Wenn es stimmt, dass viele Agenturen TV benötigen, dann sollte es leicht sein, genügend Geld aufzubringen, um zumindest ein regelmäßiges Bugfixing bis zum Ende der LTS-Version 6.2 sicher zu stellen. Wenn wir das nicht schaffen dann brauchen wir die Extension tatsächlich nicht mehr. Wer beteiligt sich? Gruß Peter -- Xing: http://www.xing.com/profile/Peter_Linzenkirchner Web: http://www.typo3-lisardo.de Facebook: http://tinyurl.com/lisardo-multimedia ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] gridelements vs fedext
Lieber Cedric auch dir sei waermstens ans Herz gelegt dich etwas mehr einzubringen. die Geduld von vielen die mit TYPO3 von T3-Kindesbeinen gearbeitet haben ist zu Ende. Mit stammtisch oder Kneipe hat das absolut nichts zu tun und mich wirst du dort als nicht Alkoholiker auch sicher wenig finden, Deinen antworten entnehme ich jedoch einerseits das du noch recht neu hier bist und auch das du das EGO System gut findest. Ohne Diskussion wie damals ueber Cooluri das ich stark promotete und heute noch taeglich anfragen auf das Cooluri Tutorial erhalte, haette es wohl autoconfig in realurl nicht in dieser Form und so schnell gegeben. Wer weiss. Langes warten macht ungeduldig und seit 2008 ist bei TYPO3 hauptsaechlich leider warten angesagt. Schau dir einfach einmal die sogenannten Rands and frueher nannten sie es Flame Wars und du wirst sehr schnell merken dass hier immer etwas bewegt wurde, selbst wenn einige mal fuer Monate deswegen eine Auszeit nahmen, um dann mit was noch besserem zurueckzukehren so wie Dmitry und auh wir setzen seither hauptsaechlich realurl wieder ein. Es ist hauptsaechlich eine und daraus dann entstehende Ideen die hier eingebracht wurden. Schau dir die Diskussionen ueber Hosting von TYPO3 an. Da hat es leider nicht so geklappt und inzwischen sind derartige Ideen bei Drupal wie ich nun feststellen musste status quo mehr oder weniger. Es gibt sogar eine distribution die es einem ermoeglicht solch eine Hosting umgebung auf seinem eigenen Server umzusetzen. AEGIR - Neben den guten ideen bedarf es jedoch auch ebenso guten wenn nicht soger noch wesentlich flexibleren Codern, die diese Inspirationen durch die Ideen dann in tolle Sachen umsetzen. Wir sind finanziell keine grossen Unterstuetzer da viele unserer Projekte nicht ums viel Geld mit TYPO3 gehen sondern um die Begeisterung mit TYPO3. Viele derer die damals mit TYPO3 begannen sind bereits abgewandert zu Contao - Typolight und zu Drupal wo man immer mehr der guten Ideen die bereits vor Jahren bei TYPO3 zur Verbesserung der Usability sorgen sollten, inzwischen umgesetzt werden. Mit Drupal 8 hat man im Grunde vieles was 2008 schon haette in TYPO3 sein koennen. Doch dann verzoegerte sich TYPO3 5 um Jahre und es geht nun mit TYPO3 6 und seinen guten Bestandteilen gerade so weiter. Kurzum Begeisterung kam in den letzten Jahren eben immer weniger auf! Updates jagten einander, instabilitaeten und dann auch noch Extensions auf extbase basis mit gleichem namen wie die pi version machtem einem das leben nicht gerade einfacher und dennoch haben wir bis heute nicht die Segel gestrichen sondern fuehrten nicht selten sehr lange Gespraeche mit denen die bereits aufgegeben hatten in der Hoffnung das TYPO3 mal user Endanwender friendlier wird. Srijan Technology, einst als grosses Beispiel in T3N gefeatured und heute Einer der grossen Supporter von Drupal die im uebrigen ein super Konvertierungs Modul von TYPO3 Seiten nach Drupal herausgebracht haben. Sie waren ganz am Anfang der Aussteiger liste, zusammen mit einigen aus den TYPO3 Kinderschuhen die man heute bei Contao wiederfindet und auch dort findet man genau das was bei TYPO3 leider wohl nicht viel zaehlt - USABILITY fuer Endverbraucher. Die Webempowered Church die nunmehr empfiehlt auf WordPress umzusteigen sind einer der letzten grossen bisherigen Austeiger und mit denen veriert TYPO3 weit mehr als nur eine Kirche. Der recht zweifelhafte Kurs von TYPO3 begann als der Koenig abdankte und hat seither nicht aufgehoert. Es sind vorallem die erheblichen verzoegerungen in der Integration von fuer Usability notwendige Bausteine von TYPO3. Ich hatte ja schon einmal einige Zitate geschrieben in einem anderen Thread wo es um den Patch der beim Multishop fehlte ging. Lese sie dir einfach einmal durch. Jeder beginnt einmals als Greenhorn Cedric bzw Newbee und auch viele der nun sehr grossen begannen damals in 2001/2002 wo auch wir mit TYPO3 quasi aufwuchsen. Die Community 2002 - 2005 unterscheidet sich jedoch sehr von dem was nun Community und von einnigen sogar ECO System genannt wird. Nachdem die WEC mit ihrem Starter Paket auch Laien es ermoeglichte eine TYPO3 aufzusetzen ging es dann richtig los mit USABILITY und super Tutorials, die noch heute ihres gleichen suchen auf Typo3.org!!! Fakt ist einfach das viele Agenturen im Grunde self tutored sind und bei vielen haengt auch sicher sehr vieles deswegen an TYPO3. Der WEC ging es so wie uns nie um das grosse Geld wie man dem Gespraech mit Mark entnehmen konnte dem zum Teil auch Kay beiwohnte, sonern es ging ihnen darum etwas gutes noch besser mit Usability fuer Enduser und Site Creators zu versehen. Nehme die diskussionen um das richtige Mappen die damals auf WEC gefuehrte wurden als Beispiel. Deren erstes Starter Paket war mitnichten so usable wie es haette sein koennen. es waren wiederum Ideen (wie Joey es beschrieb wenn ich was einbringe) die dazu fuehrten dass recht schnell dann das
Re: [TYPO3-german] gridelements vs fedext
UUps sorry gerade gemerkt das ich was falsch geschrieben hatte. East West Center ist natuerlich nicht WordPress sondern DRUPAL. Die Konvertierung und auch die Gruende weshalb namhafte Organisationen nun mehr Drupal einsetzen werden hier sehr gut beschrieben. Fuer alle die die sich einmal intensiver damit auseinandersetzen wollen. http://de.slideshare.net/AcquiaInc/making-the-move-from-typo3-to-drupal Srijan war frueher sehr aktiv in TYPO3 und ist nun sehr sehr aktiv in DRUPAL! Das Modul gibt es hier mit dem sich tt_news und tt_content elemente sehr gut in Drupal importieren lassen mit den Bildern was bei CMS2CMS angeblich nicht so gut klappt by the way ;-) Hier wird auch sehr gut beschrieben warum diese Organisationen von TYPO3 zu Drupal wechseln! http://typo3.knr.codespry.com - TYPO3 mit bekanntem Antlitz http://www.knr.gl/kl - Selbiges in DRUPAL mit mehr Funktionalitaet However, during the post-award analysis and design phase, we recognised that the project would be better of done in Drupal instead of TYPO3. We had had an experience building - See more at: http://www.srijan.net/case-study/typo3-drupal-migration-knr-case-study/#sthash.9YgpFlJG.dpuf www.indiaenvironmentportal.org.in, an environment news portal, in Drupal and the experience gained from this development led us to the belief that news and online media publishing sites should be built in Drupal. We had the benefit of having seen both the systems from close quarters. - See more at: http://www.srijan.net/case-study/typo3-drupal-migration-knr-case-study/#sthash.9YgpFlJG.dpuf Lest mehr darueber warum TYPO3 fuer solche Projekte simply OUT war! Key Reasons for choosing Drupal over TYPO3 http://www.srijan.net/case-study/typo3-drupal-migration-knr-case-study/ IN Slide Share wird auch noch einmal Deutlich auf die Probleme von TYPO3 hingewiesen und einer der Punkte ist und bleibt leider folgender: i.e. Expensive and slow maintenance/upgrade process. or difficult to implement community oriented features and Not a large developer Community compared to DRUPAL especially in US. etc TYPO3 haette schon laengst das Nummer eins CMS in Asien sein können, wenn man nur gewollt haette ;-) ein weiteres Beispiel: https://drupal.org/node/1833240 und auch hier werden die Gruende sehr deutlich benannt fuer den Wechsel! Konvertierungen sind inzwischen fast ein Kinderspiel und auf der TYPO3 Cambodia Group Facebook Seite wird taeglich dafuer geworben u.a. mit http://www.cms2cms.com/blog/drupal-or-typo3-supermassive-invasion/ sie bieten auch die Migration nach TYPO3 an natuerlich ;-) http://www.slideshare.net/CMS2CMS/how-to-migrate-from-drupal-to-typo3 Zahlreiche Lern Materialien gibt es mit den Distributionen https://drupal.org/project/distributions und hier mit unzaehligen Videos fuer alles mögliche! http://www.acquia.com/resources/tv?body_value_op=containssearch=tid_op=ortid=32 Und es gibt Statistik wie bei TYPO3 nur eben mit weit besseren Zahlen ;-) 23,787Modules https://drupal.org/project/modules1,840Themeshttps://drupal.org/project/themes 687Distributions https://drupal.org/project/distributions29,173Developershttps://drupal.org/commitlogThis week2,613Code commits https://drupal.org/commitlog5,148Issue commentshttps://drupal.org/project/issues *996,139* people in *228* countries* https://drupal.org/node/955312 speaking *181* languages power Drupal. und wer kostenlos was testen will incl slor integration sei Pantheon empfohlen: https://www.getpantheon.com Es waere so schoen man koennte wenigstens in kuerze auch fuer TYPO3 wenigstens etwas vergleichbares auf die Beine stellen. Und Distributions gebaut in THEMES ist der beste Start Punkt hierfür! So nun warten wir gespannt auf den Erfolg von Themes auf der T3Con! Liebe Gruesse Andi 2013/9/27 Andreas Becker cocop...@gmail.com Lieber Cedric auch dir sei waermstens ans Herz gelegt dich etwas mehr einzubringen. die Geduld von vielen die mit TYPO3 von T3-Kindesbeinen gearbeitet haben ist zu Ende. Mit stammtisch oder Kneipe hat das absolut nichts zu tun und mich wirst du dort als nicht Alkoholiker auch sicher wenig finden, Deinen antworten entnehme ich jedoch einerseits das du noch recht neu hier bist und auch das du das EGO System gut findest. Ohne Diskussion wie damals ueber Cooluri das ich stark promotete und heute noch taeglich anfragen auf das Cooluri Tutorial erhalte, haette es wohl autoconfig in realurl nicht in dieser Form und so schnell gegeben. Wer weiss. Langes warten macht ungeduldig und seit 2008 ist bei TYPO3 hauptsaechlich leider warten angesagt. Schau dir einfach einmal die sogenannten Rands and frueher nannten sie es Flame Wars und du wirst sehr schnell merken dass hier immer etwas bewegt wurde, selbst wenn einige mal fuer Monate deswegen eine Auszeit nahmen, um dann mit was noch besserem zurueckzukehren so wie Dmitry und auh wir setzen seither hauptsaechlich realurl wieder ein. Es ist hauptsaechlich eine und daraus dann entstehende Ideen
Re: [TYPO3-german] gridelements vs fedext
Wow ich muss mich korrigieren. Ich habe ein Paket gefunden da zwar absolut ohne features kommt und wie ein Kunde meinte it looks very blank, don't you think? aber es setzt Gridelements ein. Hinter dem Ofen holt man hier jedoch keinen hervor ;-). Es ist eher zum verkriechen. http://otto-hanika.de/twitter-bootstrap-for-typo3/ Twitter Bootstrap for TYPO3 is an extension which configures TYPO3 to use twitter.github.com/bootstrap/ for websites built with TYPO3. The extension is not available through the TER. (SCHADE!) und auch Mittwald setzt wohl auf Grid Elements in seinem 4.7 Template https://blog.mittwald.de/cms/typo3-responsive-template-als-t3d-datei/ Leider wuenschen viele Kunden so etwas nicht! Anstatt sich ueber die grosse nachfrage zu freuen wir mit Restriktion geantwortet! Keine Spur von ECO System! - wohl eher TYPO3 EGO System. Ab sofort steht unsere Vorlage unter der *Creative Commons Namensnennung 3.0 Deutschland*Lizenz. Diese haben wir auf Grund der großen Nachfrage eingeführt. Die Namensnennung erfolgt über den HTML Head der Webseite. --- mit http://gumby.caroonline.de gibt es eine weitere TYPO3 Loesung die zwar auf Fluid setzt, jedoch auch Grid Elements einsetzt. Leider kein Paket sondern nur eine Extension! bzw. mehrere! --- Fluid kommt wiederum hier zum Einsatz https://github.com/Ecodev/bootstrap_package - bootstrap introduction package --- Eine weitere sehr nette Loesung mit TemplaVoila gibt es hier http://medialis.github.io/t3bootstrap/ t3bootstrap is easy! Install your TYPO3 project as usual and before configuring the system after the 1-2-3 installer, just log into the backend, install the t3bootstrap configuration extension, set it up and you're done. It's that easy! After a successfull installation of t3bootstrap, you can extensions, such as website search, lightbox and much much more. --- eine super Loesung gibt es auch hier - ebenfalls depends on FLUID https://github.com/klaus-ger/responsive_template http://responsive-design.t3-developer.com --- aber mal ehrlich TYPO3 sieht meist recht bescheiden aus gegenueber dem Look der Konkurrenz: http://www.joostrap.com oder wie bei den mobile responsive distributions die es bei Drupal 7 gibt z.B. http://dev-restaurant.gotpantheon.com http://dev-restaurant2.gotpantheon.com (Setup der kompletten Seite in weniger als 10 Minuten! incl Beispiel Content) It is so easy and much less cost intensive than working with TYPO3 https://www.getpantheon.com/blog/drupal-distributions-everyone --- Mit http://www.typo3-themes.org koennte sich vieles aendern, doch das wartet auf Patches und auf Grid Elements grrrid. --- Bei der Aufzählung sollte man auch nicht das Modern Package vergessen. Auch hier kommt wiederum FLUID zum Einsatz. http://www.montagmorgen.at/typo3-extensions/extension-modernpackage.html - FAZIT: Wo ist ein wirklich brauchbar und vergleichbares package das Frei zugaenglich ist OHNE Beschraenkungen mit aehnlichen Features wie oben beschrieben und das voralem auch dann noch besser ist, (immerhin verzoegert es einiges an weiterentwicklung an TYPO3 IMHO). Andi 2013/9/25 Andreas Becker ab.bec...@web.de 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
Re: [TYPO3-german] gridelements vs fedext
Hallo Andreas, ich gebe Dir deutlich Recht, dass TV wesentlicher Motor des einstmals großen Erfolges von TYPO3 war. Betrachtet man heute die Webpräsenzen verbliebener TYPO3 Agenturen, so stößt man i.d.R. auf 4.5 in Verbindung mit TV. Mir war spätestens vor 3 Jahren bewusst, dass die Zukunft nicht unbedingt in TV zu suchen wäre. Also lernte ich Extbase und Fluid - und mochte es nicht. Eine Rückportierung von etwas Abstrakten, also etwas, was es noch nicht in finalisierter Version gibt, kann nur im Chaos enden. Erste Gehversuche mit FED/Flux endeten bei mir mit Fatals, was sicher ausschließlich an einer maroden Zwischenversion gelegen haben mag. Damals brachte jede Extbase Version neue (breaking) Überraschungen, und die Pflege eines komplexen Paketes muss zu dieser Zeit die Hölle gewesen sein. Mit 4.7 tauchte plötzlich GE in der Liste der Core-Projekte auf - inklusive der Hoffnung, dass man nun wohl auch im Core-Team die Notwendigkeit einer beherrschbaren Templating Lösung eingesehen hätte. Dies war ein Trugschluss, aber im Nachhinein für mich irrelevant. Anfangs machte ich genau den Fehler, den alle TV zu GE Migranten machen. Ich bastelte mir einen eigenen Text mit Bild unter intensiver Flexform Nutzung. Da GE, im Gegensatz zu allen Fluid Varianten, extrem kompakt ist, fiel es mir nicht schwer, den Quellcode zu verstehen (die Doku war seinerzeit noch nicht sehr vollständig). Je tiefer ich einstieg, desto deutlicher wurde mir, wie man es mit GE richtiger macht, als ich bislang. Seit etwa einem Jahr arbeite ich an einer Extension, welche die Möglichkeiten von Twitter Bootstrap (3) vollinhaltlich in TYPO3 abbildet. Dies war und ist mit GE a piece of cake - soll heißen, dass der GE-relevante Teil davon komplett fertig ist. Seit etwa 3 Wochen arbeite ich am letzten, fehlenden Teil: Einem Hook für CSC. Und auch der wird fertig werden. Danach benötige ich für eine komplette, komplexe Website noch exakt 4 Extensions: GE, News, RealUrl und meine. Viel schlanker geht es derzeit nicht. Und würde ich Versionierung tatsächlich verstehen, alles wäre versionierbar. Du erwähnst den Begriff Conditional in Bezug auf die Kostenseite der Nutzung von GE. Da ich mit TYPO3 derzeit kein Geld verdiene, gebe ich auch keines dafür aus - abgesehen von zahllosen Stunden, die ich investiere, weil ich mir Basisforschung erlauben kann. Ich arbeite ausschließlich mit der im TER/Forge für Jede(n) verfügbaren Version von GE. Betrachtest Du die Historie von GE, so kommst Du irgendwann an den Punkt, wo GE dann doch keine Core Extension mehr sein sollte. Wäre wohl einfach zu vernünftig gewesen. Jetzt hat man als Entwickler, der auch mal essen möchte, genau zwei Möglichkeiten. Das Ding in die Tonne hauen, oder dafür sorgen, dass man sich die weitere Entwicklung ohne Mittel vom Core erlauben kann. Dadurch kam es zur ersten, mir bekannten Crowdfunding Kampagne zu TYPO3. Diese hat dazu geführt, dass die für Jeden verfügbare Version heute ziemlich ausgereift ist. Bleibt das Problem, wie man sich denen gegenüber erkenntlich zeigen kann, die das Projekt angeschoben und finanziell unterstützt haben. Soviel ich weiß, gibt es für diese Gruppe einen geschützten Bereich, in dem zusätzliche Beispiele, fertige Elemente und first hand Infos verfügbar sind. Dies ist nur fair. M.W. gibt es dort keine bessere GE Version, sondern nur bessere Infos zur für alle verfügbaren TER Version. Ich denke, man hat heute zwei Wege zum Ziel. Per FED/Flux/../.. oder eben GE. Die erste basiert ausschließlich auf Extbase/Fluid, der andere erlaubt Fluid oder TS. Welchen man beschreitet, ist persönlichen Präferenzen überlassen. Einen Core Weg gibt es leider nicht. M.E. das derzeit größte Manko des aktuellen TYPO3. Grüße, Thomas ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] gridelements vs fedext
Hallo Joey; Danke für deine Erläuterungen. Ich hätte mich über einen darüberhinausgehenden Dialog gefreut, dieser kann anscheinend leider nicht hier stattfinden, da unsachlich und vor Allem OT herein gegrätscht wird. Viele Grüße, Cedric Zitat von 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 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.orghttp://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
Re: [TYPO3-german] gridelements vs fedext
@Andreas. Korrigiere bitte die Vergleichsliste hinsichtlich der Features von TV vs. GE wieder auf einen Stand, der den Tatsachen entspricht. Drag In gibt es in TV nicht. Kopieren per Drag Drop meines Wissens nach auch nicht. Kopien von einer andern Seite holen, ohne die aktuelle Seite zu verlassen kann TV ebenfalls nicht. etc. pp. Dies Punkte können zwar im Prinzip von jedem verändert werden, sollten aber dann doch bitte die Realität wiedergeben und nicht irgendeinen Wunschtraum. Dazu gehört übrigens auch der Punkt Free to use. Keine Ahnung, wer die Dreistigkeit besessen hat, das für Gridelements auf Conditional zu setzen, denn Gridelements wurden von Anfang an aus dem Telekom-Projekt heraus frei für alle zur Verfügung gestellt und dies hat sich auch durch die Crowdfunding Kampagne nicht geändert! Zu den weiteren Tastachen, die Du Dir - wie so oft auf Halbwissen basierend - zurechtbiegst: 1. Gridelements wäre von Anfang an Kays erste Wahl für Themes gewesen, wenn er gewusst hätte, dass man sie mit Hilfe von TSconfig über Files konfigurieren kann und nicht nur über Datensätze. Dies haben wir gemeinsam auf den Devdays klären können und uns in einem Workshop mit locker 40 Leuten mehrheitlich dafür entschieden, Gridelements als Basis für Themes zu verwenden und ein Crowdfunding zur Finanzierung der THEME PACKAGES zu starten. Dies ist jedoch kein Hauruck-Prozess, sondern eine Entwicklung, die zum einen maßgeblich von TYPO3 6.2 abhängt und zum anderen eine sinnvolle Planung und Roadmap benötigt. 2. Die Bremse liegt nicht bei Gridelements sondern beim CORE, denn dort wird ein Patch benötigt, damit die im Core verfügbaren Backend-Layouts ebenfalls mit Hilfe von TSconfig so konfiguriert werden können, wie das mit Gridelements schon lange funktioniert. Dieser Patch wurde von Jigal schon für die Version 6.0 blockiert und er hat diese Blockade erst kürzlich zurückgezogen, weil wir eine Kompromisslösung gefunden haben, die es Extensions wie Themes ermöglicht, TSconfig basierte Layouts zu nutzen. Das hat mit dem Einsatz von Gridelements überhaupt nichts zu tun. Wir sind vielmehr der einzige Motor hinter diesem Patch, haben unsere Budgets dort mit investiert und werden von einigen Core-Developern unterstützt, damit die Lösung endlich ihren Weg in TYPO3 6.2 findet. 3. Gridelements funktioniert problemlos auf Basis von FLUID - wir haben dafür spezielle virtuelle Datenfelder vorgesehen, damit man ggf. sogar das komplette Rendering aller Rohdaten über FLUIDTEMPLATE abfrühstücken kann. Wenn das Deiner Meinung nach die Zukunft ist und daran kein Weg vorbei führt: Gridelements bieten Dir genau diesen Weg! 4. Gridelements selbst liefern lediglich die Basis für ein strukturiertes Backend und genau diese Aufgabe werden sie im Rahmen von THEMES übernehmen. Die Frontendausgabe der Packages wird ggf. über FLUID oder je nach Geschmack des Entwicklers mit TypoScript oder auch einer Kombination aus beidem erfolgen. Die eigentliche Basis für die Themes werden aber Frameworks wie Bootstrap, Foundation, Skeleton o. ä. sein. Sprich: Wenn das Basis-Paket aus Template-Sprache und Frontend-Framework steht, brauchst Du für Themes lediglich CSS und JS. 5. Dass es einen Trend gibt, ähnliche Packages auf Fluidcontent aufzusetzen, ist unbestritten, jedoch sollte man den Nutzern zumindest mitteilen, dass sie damit die Nachteile von Extbase und das altbekannte XML-Problem aus TemplaVoila-Tagen mit kaufen, denn das ist den meisten vermutlich nicht in seiner gesamten Tragweite bekannt. 6. Wie schon an anderer Stelle in diesem Thread beschrieben: Gridelements != FCE - GE dienen vor allem der Strukturierung und nicht dazu, neue EIngabeformulare für bisher nicht vorhandene Inhalts-Elemente zu liefern. Dafür gibt es TCA und wir haben vor, dazu einen Wizard zu liefern, der völlig ohne XML basierend auf tt_content und einer Minimaltabelle für Snippets die Konstruktion neuer Elemente ermöglicht. Das wäre dann Kesk UND Schokolade. Dies sind nur die wichtigsten Fakten, die hoffentlich dazu beitragen eine erneute Serie von Rants im Romanformat zu verhindern. Hör bitte endlich auf, Dinge als den alleinseligmachenden goldenen Hammer zu verkaufen und lass uns gemeinsam eine sinnvolle Lösung erarbeiten. Wir sind mit Kay dabei und stellen das Ganze auf der TYPO3 Konferenz in Stuttgart vor. Danach gibt es dann einen Sprint bei uns in Clausthal, bei dem wir die Roadmap und die nötigen Features festlegen wollen, die Gridelements liefern müsste, um die User-Experience noch weiter zu verbessern. Wenn Dir das nicht schnell genug geht, kann ich leider nichts dran ändern. Du kannst Dich aber gern über forge.typo3.org einbringen und entsprechende Feature-Requests machen, die wir beim Sprint mit berücksichtigen können. Danke! 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:
Re: [TYPO3-german] gridelements vs fedext
Am 25.09.2013 13:22, schrieb Cedric Ziel: Hallo Joey; Danke für deine Erläuterungen. Ich hätte mich über einen darüberhinausgehenden Dialog gefreut, dieser kann anscheinend leider nicht hier stattfinden, da unsachlich und vor Allem OT herein gegrätscht wird. Andreas ist halt gerade wieder im Rant-Modus :-) Ich hoffe, dass meine Antwort das relativieren kann, falls nicht, fände ich das schade. Wir können hier aber gern trotzdem schauen, wie wir zu Ergebnissen kommen, die für alle hilfreich sind, zumal Gridelements und Fluidcontent problemlos in derselben TYPO3-Instanz nebeneinander genutzt werden können. Frohes Schaffen! 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
Re: [TYPO3-german] gridelements vs fedext
Am 24.09.2013 07:44, schrieb Martin: Wer kann mir bitte den Unterschied zwischen gridelements und fedext erklären? Gibt es einen Unterschied? Wenn ja, welchen? Wer hat Erfahrungen mit einer dieser Extensions gesammelt und kann ausführlich seinen Statusbericht abgeben? Moin moin. Hier mal eine Gegenüberstellung von Gridelements und Fluidcontent: http://vschart.com/compare/grid-elements-typo3-extension/vs/fluid-content-engine In den Kommentaren steht auch noch einiges und Du kannst bei Bedarf auch noch TemplaVoila mit reinnehmen, dann gibts aber keine Kommentare. Als Teamlader von Gridelements kenne ich mich damit natürlich besser aus, von daher ist die Aussage nicht ganz neutral: Der Hauptunterschied besteht darin, dass Du bei Fluidcontent sowohl im Backend als auch im Frontend ausschließlich mit Fluid unterwegs bist und die Datenhaltung wie auch bei Templavoila ausschließlich über XML in einem einzelnen Feld erfolgt, während Gridelements Dir mit TypoScript, Fluid- und HTML-Templates verschiedene Möglichkeiten des Templatings bieten und die Datenhaltung bis auf das übliche Plugin-Flexform normalisiert erfolgt. Bei Fluidcontent läuft unter der Haube Extbase, bei Gridelements ist es das Inline Relational Record Editing des TYPO3 Core. Beide haben verschiedene Vor- und Nachteile z.B. hinsichtlich Sprachen und Workspaces, die Du aber an anderer Stelle finden kannst. Fluidcontent ist flexibler und komfortabler was das Erstellen von Elementen angeht, die unter TemplaVoila als FCE bekannt sind. Das ist gleichzeitig auch der Schwerpunkt von Fluidcontent. Gridelements dienen vor allem der Strukturierung und Gruppierung von Inhalten für die Redakteure und liefern mit Drag In von neuen Elementen, Drag Drop Kopien, Kopien von anderen Seiten etc. zusätzliche Komfort-Features, welche die Arbeit im Backend erheblich beschleunigen. Zudem werden Gridelements die Strukturbasis der zukünftigen TYPO3-Themes sein, die dieses Jahr auf der T3CON vorgestellt werden und für TYPO3 6.2. LTS Anfang nächsten Jahres an den Start gehen. Ich hoffe das reicht aks Übersicht :-) 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
Re: [TYPO3-german] gridelements vs fedext
Tagchen, Auch ich bin leider nicht ganz un-voreingenommen, da ich mit Claus und Björn zusammen an der FluidTYPO3 Erweiterungsfamilie arbeite. Ich habe zudem niemals mit gridelements gearbeitet. Und nur Einführungsvorträge gesehen. Ich würde Joey grundsätzlich zustimmen; was Strukturelemente angeht, macht gridelements einen guten Job; geht es um Redakteursfreundliche Konstruktion des Backends, würde ich widerrum fluidcontent einen Plus-Punkt geben. Unser Ansatz ist der Folgende: Mit fluidcontent (und fluidpages für Page Templates natürlich auch) kann der Integrator in der Entwicklung sehr schnell Geschwindigkeit aufnehmen, weil er sich nur in Fluid bewegt. Sämtliche Formular- und Strukturelemente werden mit Fluid beschrieben, und erlauben so die schnelle Konstruktion von einfachen bis sehr komplexen Flexiblen Inhaltselementen. Zusammen mit EXT:vhs versuchen wir eine One-Stop Lösung für 90% der Anwendungsfälle zu konstruieren, und soviel wie möglich im Template abzubilden um a.) Alles Versionierbar zu halten (Es ist schließlich alles ein XML Dialekt [Fluid]) b.) Einen riesigen Haufen TypoScript loszuwerden 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. Warum ich aber dennoch für fluidcontent [für flexible Inhalte] plädiere: - Die (wirklichen) Alternativen fehlen - Geschwindigkeit in der Entwicklung - Das Ökosystem (flux als Basis kann sowohl für Seitenlayouts, wie auch für flexible Inhalte oder BackendModule verwendet werden) - VHS ist im Fluid Kontext als Toolkit verfügbar Das war sehr voreingenommen. Entschuldigt ;) Mein letzter Beitrag in dieser Mail soll sein: fluidcontent eignet sich besser für FCE's, gridelements ist mE eindeutig mehr auf Strukturelemente ausgelegt und beide Anwendungsfälle sollten nicht verwechselt bzw nur einzeln betrachtet werden. Ich hoffe, ich habe jetzt niemandem auf die Füsse getreten, und würde mich ansonsten über einen ausgewogenen Dialog freuen. Viele Grüße, Cedric Zitat von JoH asenau i...@cybercraft.de: Am 24.09.2013 07:44, schrieb Martin: Wer kann mir bitte den Unterschied zwischen gridelements und fedext erklären? Gibt es einen Unterschied? Wenn ja, welchen? Wer hat Erfahrungen mit einer dieser Extensions gesammelt und kann ausführlich seinen Statusbericht abgeben? Moin moin. Hier mal eine Gegenüberstellung von Gridelements und Fluidcontent: http://vschart.com/compare/grid-elements-typo3-extension/vs/fluid-content-engine In den Kommentaren steht auch noch einiges und Du kannst bei Bedarf auch noch TemplaVoila mit reinnehmen, dann gibts aber keine Kommentare. Als Teamlader von Gridelements kenne ich mich damit natürlich besser aus, von daher ist die Aussage nicht ganz neutral: Der Hauptunterschied besteht darin, dass Du bei Fluidcontent sowohl im Backend als auch im Frontend ausschließlich mit Fluid unterwegs bist und die Datenhaltung wie auch bei Templavoila ausschließlich über XML in einem einzelnen Feld erfolgt, während Gridelements Dir mit TypoScript, Fluid- und HTML-Templates verschiedene Möglichkeiten des Templatings bieten und die Datenhaltung bis auf das übliche Plugin-Flexform normalisiert erfolgt. Bei Fluidcontent läuft unter der Haube Extbase, bei Gridelements ist es das Inline Relational Record Editing des TYPO3 Core. Beide haben verschiedene Vor- und Nachteile z.B. hinsichtlich Sprachen und Workspaces, die Du aber an anderer Stelle finden kannst. Fluidcontent ist flexibler und komfortabler was das Erstellen von Elementen angeht, die unter TemplaVoila als FCE bekannt sind. Das ist gleichzeitig auch der Schwerpunkt von Fluidcontent. Gridelements dienen vor allem der Strukturierung und Gruppierung von Inhalten für die Redakteure und liefern mit Drag In von neuen Elementen, Drag Drop Kopien, Kopien von anderen Seiten etc. zusätzliche Komfort-Features, welche die Arbeit im Backend erheblich beschleunigen. Zudem werden Gridelements die Strukturbasis der zukünftigen TYPO3-Themes sein, die dieses Jahr auf der T3CON vorgestellt werden und für TYPO3 6.2. LTS Anfang nächsten Jahres an den Start gehen. Ich hoffe das reicht aks Übersicht :-) Joey -- Wenn man keine Ahnung hat: Einfach mal Fresse halten! (If
Re: [TYPO3-german] gridelements vs fedext
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
Re: [TYPO3-german] gridelements vs fedext
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
