82 Reaktionen zu “TemplaVoila auch für 6.2 LTS”

Kommentare abonnieren (RSS) oder TrackBack URL

Schade, dass man dieses alten Zopf nicht endlich komplett abschneidet.

Name am 25. Juni 2013 um 10:16

TV hatte immer seine Stärke im Bereich FCE. Bis jetzt habe ich keine Alternative gefunden, um schnell und einfach neue angepasste Inhaltselemente für Redakteure zu bauen.

Oder kennt ihr da bessere Lösungen (gerne mit Link)?

christian am 25. Juni 2013 um 11:06

dieser „alte Zopf“ wurde für dassault systems entwickelt und hat einige enterprise projekte laufen auch heute noch erfolgreich auf dem Konzept. Wenn shcon Bashing, dann konstruktiv: nennt mir eine bessere/einfachere Alternative, die funktioniert – für Redakteure wie für Entwickler … go ahead !

gast am 25. Juni 2013 um 11:27

super. freut mich das TV doch noch weiterentwickelt wird. aber für alternativen bin ich offen, wenn jemand eine empfehlung hat, nur her damit!

Thierry am 25. Juni 2013 um 14:53

@gast.
Backend Layouts und Gridelements.
Hat bis jetzt super funktioniert.

Patrick am 25. Juni 2013 um 15:15

TV ist wirklich die einfachste Methode, FCEs zu erzeugen und generell solche BE-Layouts zu steuern.

Ich bin nun nicht der erfahrenste TYPO3-User, aber diese Onbord-Backend-Layouts finde ich nicht wirklich zufriedenstellend.

Beim Templating hat TV den Vorteil, dass man die Seite so erzeugen und anzeigen lassen kann, wie sie letztendlich aussehen soll. Mit Fluid geht das schlecht, wenn man die ViewHelper dazwischen klemmen muss.

Wie auch immer. FCEs sind halt ein Kapitel für sich, und das scheint nicht kurz zu sein.

Falls jemand noch weitere Vorschläge oder Beispiele hat, FCEs zu erzeugen: gerne hier posten. Danke schon mal.

stdWrap am 25. Juni 2013 um 18:02

Hallo zusammen, eine gute Alternative zu TV finde ich die Extensions von Claus Due. Damit steuere ich die Backend-Layouts und kann einfach FCE’s via Fluid-Templates erstellen. Info gibt’s unter: http://fedext.net/overview.html … MfG

Jürgen am 26. Juni 2013 um 00:27

Niemand braucht für Gridelements und BackendLayouts Fluid Templates einzubinden.
Keine Ahnung wieso ich TV einsetzen soll, wenn mir TYPO3 schon alles bietet. Ich sehe da echt keinen Vorteil. Gridelements und BE Layouts bietet genau dasselbe wie ein TV mit FCE und all meine Grids kann ich genauso in jedes Projekt importieren.

Patrick am 26. Juni 2013 um 12:14

TemplaVoila hatte einfach den enormen Vorteil, dass man einen Designer mit HTML/CSS-Knowhow selbstständig Seiten- und Content-Vorlagen gestalten lassen konnte. Mit BE-Layouts, Fluid und Gridelements versteht das gesamte Inhaltsgerüst nur noch ein TYPO3-Developer mit mittelmäßig bis viel Erfahung in Typoscript. Das macht die Projekte anspruchsvoller und teurer.

Ich frage mich – ganz ehrlich gesagt – was genau die TYPO3-Community da vorhat und wer die aktuellen Entwicklungen steurt. Klar ist doch, dass durch die Anhebung des technischen Niveaus auf allen Ebenen ein großer Teil der Community abgeschnitten wird. TYPO3 hat immer mit seiner großen Community geworben, mit 1000en von frei verfügbaren Extensions, lebhaften Foren etc. Wenn man aber bald erstmal 2 Bücher zu Typoscript lesen muss und erstmal die hohe Kunst der SW-Entwicklung an der Uni erlernen muss um ein einfaches Template samt FCEs zu realisieren, dann bleiben nur noch ein paar größere Player übrig, die das CMS nutzen werden und können.

Ich frage mich: Wer will das? Die breite Community oder die Geldgeber, die offenbar bei TYPO3 das Ruder in die Hand genommen haben?

Bjoern am 26. Juni 2013 um 13:41

@Jürgen: Danke für den Link. Das schaue ich mir mal genauer an 🙂

stdWrap am 26. Juni 2013 um 19:02

Ich hab fast hundert Projekte mit TV betreut, und hab fast nie FCE gebraucht. Eigentlich immer waren einfache Inhaltselemente mit Rahmen drum, über denn die Ausgabe mit CSS / Javascript verändert wird, die einfachere (und schnellere!) Alternative. TV war toll, aber es hat auch genervt, dass die Daten nicht ordentlich in der DB abgelegt waren.

die Tante Jensen am 27. Juni 2013 um 12:19

Hier muss ich Christian und Patrick leider voll zustimmen.

Kein Ersatz kommt derzeit an die Flexibilität und Userexperience von TV heran und ich habe schon alles an Templating auprobiert.

Marco am 27. Juni 2013 um 14:20

Für FCEs gibt es DCE. Außerdem arbeitet Kai gerade an ext:themes und Oli an ext:mapper.

Es gibt noch eine ganze Reihe weiterer Extensions mit denen man FCEs bauen kann.

Philipp Gampe am 29. Juni 2013 um 10:05

Ob solche cowboycoding extension wirklich die lösung sind, wage ich zu bezweifeln.

name am 30. Juni 2013 um 00:12

Für das Nutzen von Fluid-Viewhelpern braucht man keine „hohe Kunst der Software-Entwicklung“ studiert zu haben. Die sind relativ einfach, schnell gelernt, und idiotensicher zu verwenden:
http://wiki.typo3.org/Fluid

Christian am 02. Juli 2013 um 12:19

Für vernünftige und wartbare Extension muss der Entwickler schon etwas mehr als nur ein paar PHP-Funktionen und Klassen zusammenfrickeln könnnen. Sonst endet das wieder wie bei tt_news und unzähligen anderen Extension, wo nach Ausscheiden des ursprünglichen Entwicklers keiner mehr Lust hatte den Spaghetticode weiter zu pflegen und man sich glücklich schätzen können, wenn es doch noch von irgendjemand so zusammengehackt wird, dass es bei der nächsten Version noch halbwegs funktioniert.
Da hilft auch das hochgelobte FLUID und Co nicht. Wenn du mal in den Code der tx_news Extension von Georg Ringer reinschaust, wird einem stellenweise übel….

peter am 03. Juli 2013 um 23:39

Gibst du jetzt der news-Extension von Georg Ringer die Schuld am Spaghetti-Code der alten tt_news-Extension oder hab ich den Kommentar gerade falsch verstanden?

Christian Eßl am 04. Juli 2013 um 08:43

Nein, wenn du ordentlich lesen würdest, sähest du, dass dort tx_news steht. Wäre mir im übrigen auch neu, dass tt_news auf Extbase und Fluid bassieren würde.

peter am 04. Juli 2013 um 16:14

Muss dieser Tonfall sein? Ich bitte um mehr Höflichkeit, danke.

ein anderer Peter am 04. Juli 2013 um 22:44

Hallo anonymer Peter,

mal ganz abgesehen vom Ton den ich einfach mal korrigiere wäre es interessant zu wissen was dich konkret stört.

Wir können auch gerne beim nächsten Event drüber plauden

Georg Ringer am 10. Juli 2013 um 11:17

Hallo!

Meine Meinung, als TYPO3-Developer ist, das niemand Templavoila benötigt um eine gut TYPO3-Seite zu erstellen.
Ich persönlich kenne keinen Developer der TV tatsächlich mag, oder für sinnvoll erachtet.

Fakt ist auch, das Fluid und ExtBase nicht umsonst entwickelt wurden.
Dieser Schritt war notwendig um auch in Zukunft eine gute Software liefern zu können. Extension wie TemplaVoila haben, auch wenn sie gut gemeint waren, nur dazu geführt das leute mit halbwissen Projekte erzeugt haben, die unplegbar sind und kaum Qualität haben.
Es ist doch so, je höher der Anspruch an den Programmierer aufgrund der Software, desto höher ist am Ende auch die Qualität.

Ich denke diese hat in den letzten Jahren bei vielen Projekten, durch Entwickler mit Halbwissen stark gelitten.
Das hat sicherlich auch die TYPO3-Community ungern gesehen, da TYPO3 seit langem eigentlich für qualitativ hochwertige Projekte steht.

An diesen Punkt möchte ich Allgemein betrachtet gerne wieder hinkommen, da ich mittlerweile wirklich zu viele Schlecht gemachte Projekte fixen musste die von anderen Programmierern kamen.
In den meisten Fälle mit TemplaVoila.

MfG
Christian

Christian am 08. August 2013 um 15:27

Alternativen zu TemplaVoila:
Fluid & Backendgrid

Und um TypoScript zu verstehen benötigt man mit sicherheit keine 2 Bücher.

MfG
Christian

Christian am 08. August 2013 um 15:29

Mit TemplaVoila bekommt auch ein Anfänger auf Anhieb keine Seite hingezaubert. Wenn man dasmit mal komplexe FCE’s aufgebaut hat und die noch an eigene Exetnsion gekoppelt hat ist piBase/Extbase/Fluid dagegen ein Spaziergang. Das Workarounding um nur an eine bestimmte UID zu kommen mittels TS war schon hefig.

Die Stärke lag m.M. nach in den FCE’s/Grid + Drag’n’Drop + Haptik für den Redakteuer. Da kam bis jetzt nichts wirklich ran.

Benutze seit einiger Zeit die Fedext-Komponenten vom Claus. Leider sind dort die Updates eine Katastrophe (Breaking changes).

Marco am 08. August 2013 um 23:05

@Marco: Grid + Drag’n’Drop + Haptik sind seit TYPO3 6.x unnötig.

Und FCEs habe ich nach 100 Projekten in und mit verschiedenen Agenturen noch nie gebraucht.

Ansonsten gibt es noch DCE für die jenigen die unbedingt leicht ein eigenes Content Element erstellen möchten.

Ich sehe noch immer keinen Grund TemplaVoila nutzen zu müssen.
Es ist in der jetzigen Situation vollkommen überholt, denn warum sollte ich eine Extension das erledigen lassen was der Core bereits mitliefert.
Das erzeugt am ende nur noch mehr Code der unnötig mitgeladen werden muss.

Zeitverschwendung..

MfG

Christian am 08. August 2013 um 23:50

Setze auch derzeit Fedext-Extensions von Claus Due in aktuellen Projekten ein und bin recht zufrieden damit, abgesehen von den dort eher häufig auftretenden Breaking changes, die Marco schon angesprochen hat.
Ein häufiger Kandidat sind da z.B. die verwendeten XClasses, die bei nahezu jedem TYPO3/Flux-Update wieder mal dafür sorgen, dass das Kopieren von Datensätzen in den Modulen kommentarlos fehlschlägt. Wenn man weiß, dass das Problem in der Regel von veralteten XClasses herrührt, kein Problem, aber weniger erfahrene TYPO3-Nutzer dürften da vermutlich schnell verzweifeln.

Christian Eßl am 09. August 2013 um 08:32

Hallo zusammen,
Ich beobachte mit Entsetzen wie TV von Entwicklern gebasht wird die damit nur Ihre eigene Sichtweise der Welt für global erklären.

Mich würde es mal interessieren wie Ihr mit Kunden umgeht die über große Internetseiten mit TV verfügen und Updaten wollen?

Helmut W am 28. Oktober 2013 um 13:42

Sie zum Umstieg auf eine moderne und gepfelgte Extension bewegen. Man kann nun mal diesen Uraltmurks nicht ewig supporten. IE6-Support wurde wurde ja auch eingestellt.

user am 29. Oktober 2013 um 14:35

TV….mhmmm
Ich fasse mal zusammen:
– Fehleranfällig
– Überholt
– Performanceraubend
– Umständlich in der Bedienung (Mapping:-()
– Gibt ordentlich bewährte Lösungen wie Gridelements
– Flexform lässt sich nicht ordentlich mit TS-Bordmitteln auslesen.

Wozu dann noch weiter supporten, nach dem der Author auf seiner Seite erzählt, dass er mit dem Weg wie sich TYPO3 entwickelt nicht leben kann und immer so viel leute böses erzählen? 🙂

TV=DISLIKE!

Mathias Bruckmoser am 08. November 2013 um 11:21

Ich bin einer von den semi Entwicklern der viele Zeit und Nerven investiert hat, um mit Typo3 Lösungen zu realisieren.
Es ist etwas schockierend, wie wenig wert einigen Entwicklern die Konsistenz der Typo3 Entwicklung erscheint.
Würde Templa Voila einfach sterben wäre das für Anbieter mit kleineren Etat aber hunderten oder tausenden an Seiten eine Katastrophe.
Was ist nun eigentlich Stand der Dinge? Lebt Templa Voila weiter oder ist es im Prinzip begraben?

ralf am 14. November 2013 um 14:27

@ralf … wenn dir die TYPO3 CMS Entwicklung nicht kontinuierlich genug ist, dann nimm doch Drupal. Da kannst du dich bei jedem Update über komplett neu zu schreibene Extensions freuen.

Sorry, aber es ware nicht genug Devs/Agenturen an einer Wartung von TemplaVoila interessiert, so dass das Projekt eingeschlafen ist. Für 6.2 LTS wird es ein kompat Release geben, dass war es aber dann wohl auch.

Philipp Gampe am 14. November 2013 um 22:06

@Helmut W: Bei solchen Kunden raten wir dringend zu einem Update und führen das auch geordnet mit ihnen durch.
Auch vollkommen ohne Probleme.

@ralf: also um das mal fest zu halten, weil entwickler kleinerer Unternehmen keine lust hatten sich weiter zu bilden soll sowas wie TV weiter entwickelt werden?
Klingt für mich irrsinnig.
Denn mal ernsthaft, der Etat einer Agentur hat nichts mit der Weiterbildung der Mitarbeiter zu tun. Und auch wenn das nur meine Meinung ist, aber was hält einen TYPO3-Entwickler davon ab sich privat mal zu belesen und zu entwickeln?
Meine Kollegen und ich machen das ständig.
Man kann sich doch nicht darauf ausruhen das etwas wie TV, das wirklich heute schlecht ist, weiter entwickelt wird.
Und das nur weil man zu faul ist.

Ich habe unzählige Internetseiten mit TV gesehen, einige bis zu 8 Jahre alt und einige nicht älter als ein Jahr.
Sie haben alle einiges gemeinsam, unpflegbar, nicht performant und grausam von der Qualität.

Aber wie schon gesagt, wer auch unter TYPO3 6.2 weiterhin sehr einfach individuelle Contentelemente erstellen möchte kann das ja mit DCEs machen.
Und zusammen mit Gridelements lassen sich auch die unsinnigen Verschachtelungen von TemplaVoila reproduzieren.
Zum Glück aber qualitativ auf einem ganz anderen Level. 😉

MfG

Christian am 15. November 2013 um 01:30

Das Informationsmanagement um die Abkündigung von Templavoila wirkt tatsächlich hoch unprofessionell.
Trotz offenbar guter Gründe Templavoila auslaufen zu lassen scheint mir das Auftreten einiger hochqualifizierter Typo3-Entwickler von Hochmut geprägt zu sein. Anstatt die Ängste der vielen Seimiprofessionellen oder Teilzeit-Entwickler zu schüren sollte von offizieller Typo3-Seite eine Alternative oder alternatives Vorgehen zu Templavoila unter einem „Produktnamen“ veröffentlicht werden. Das ganze scheint eher ein Informations- als ein Typo3-Problem zu sein.
MfG

Bernhard am 07. Dezember 2013 um 13:46

@Bernhard:
Sinnvolle äqui­va­lente Lösungen wurden bereits von einigen hier dargelegt.
Und ich finde es nehrlichgesagt nicht von Hochmut geprägt wenn man sich als TYPO3-Entwickler über Jahre viel Erfahrung und Wissen erarbeitet hat. Wenn andere Entwickler diesen Aufwand nicht betreiben möchten, ist das okay, aber dann sollte man in einem stätig wachsenden System nicht erwarten das alles für solche semiprofessionellen Entwickler optimiert wird.

Ich persönlich möchte keine Angst schüren, mehr das Bewusstsein schaffen das einem nicht alles abgenommen wird und das man eben stetig weiter lernen muss.
Und das ist denke ich auch nicht zu viel verlangt. Ich kann es einfach nicht mehr hören wie rumgejammert wird weil es „TV“ nicht mehr geben wird, obwohl Backendgrids und DCEs ebenso simpel wie schnell zu erzeugen sind.
Und auch weit besseren Code erzeugen.
Klar sind eben nicht alle dinge damit möglich, aber dafür kann man sich ja schnell ein Plugin bauen ohne viel Aufwand, wenn man sich denn mal etwas mit Extbase und Fluid auseinandergesetzt hat.

Vielleicht ist es doch eher ein Verständnis-Problem.

MfG

Christian am 09. Dezember 2013 um 13:49

Aber es stimmt schon, dass die Tonalität so ist, als würden sich einige Entwickler freuen, wenn die sogenannten „Semiprofessionellen“ auf der Strecke bleiben … weil sie aus Ihrer Sicht „zu faul“ sind, sich entsprechend einzuarbeiten.
Aus meiner Sicht ist aber Typo3 gerade deshalb so erfolgreich, WEIL es auch aus Programmierersicht Semiprofessionellen Möglichkeiten gibt, Dinge zu realisieren, die mit zur Hilfenahme externer Dienstleister nicht verwirklicht werden können.
Würde es nicht dieses Heer an Typo3 Freunden geben, hätte Typo3 niemals die Bedeutung.
Im Bereichen, wo die Etats nicht so knapp bemessen sind, gibt es ja genug professionelle Alternativen.
Es gibt Websites die haben vielleicht einen schönen Code, sind aber unprofessionell gestaltet … und es gibt Websites die haben unprofessionellen Code sehen, aber extrem professionell aus.
Es spricht doch nichts dagegen, dass es Coder gibt, die Websites gestalten möchten und Gestalter gibt, die die ihre Gestaltung auch technisch umsetzen möchten.
Die Zukunft liegt sowieso darin. Wenn Typo3 sich mehr zu einer texhnischen Plattform entwickelt, die für Designer nur schwer zugänglich ist, wird es sicher andere Plattformen geben. Die Zukunft liegt im vereinfachten Handling – auch wenn es nicht allen sympathisch ist.
Das Typo 3 in der Agenturszene derart verbreitet ist, dass auch große Konzerne Websites damit realisieren lassen, liegt vor allen Dingen daran, dass die Agenturen damit sympatisieren. Und das liegt nicht zuletzt daran, das viele, die dort arbeiten sich schon einmal semiprofessionell mit Typo 3 auseinandergesetzt haben.

ralf am 09. Dezember 2013 um 15:19

Sorry, aber ihr redet hier am Thema vorbei.

Seit 8 Jahren setze ich Typo3 ein und supporte es und primär hatte ich bis Ende 2012 TV verwendet.
Das ist nunmal historisch bedingt, da Typo3 ja nicht wirklich gute Lösugnen bot, um „Anwenderfreundliche“ Seitenelemente zu erstellen, ohne gleich aus jeder Mücke eine eigene Extension zu erstellen.

Die TV-FCEs erfüllten ihren Zweck einwandfrei und dieses geflame „Programmerier ohne Ahnung“, da könnte ich durch die Decke gehen.

TYPO3 hat halt historisch gesehen auch viele Wandlungen durchgemacht und deshalb sind auch viele Extensions so „verschwurbelt“ (heise.de-Slang). Über den, mich schon immer störenden, TypoScript Ansatz wollen wir erst garnicht reden.

Das NEOS nicht vom start weg ein Megaerfolg wurde, das sollte auch mal zu denken geben. Schließlich gibts ja jetzt nicht ohne Grund TYPO3 V6 😉

Viele größere Seiten mit vielen Redakteuren setzen nun das System ein und da wird „nicht mal eben so“ ein seit jahren funktionierendes System ersetzt, in welcher Realität lebt ihr?

Dieter am 20. März 2014 um 16:40

Wir gewöhnen uns wegen der hier und da schon störenden Probleme/Inkonsistenzen, der schlechten Zukunftssaussichten und der Tatsache, dass der Core UI-mäßig ganz gut aufgeholt hat auch gerade TV ab.

Neben den FCEs, die wir schon etwas vermissen, fühlt sich das Original- Seitenmodul allerdings teilweise schon ein wenig wie ein Rückschritt an. Gibt es z.B. eine einfache Möglichkeit, die Vorschau-Texte der Inhaltsemelente zu kürzen, wie mit mod.web_txtemplavoilaM1.previewDataMaxLen?

GangRel am 24. März 2014 um 10:44

Jetzt muss ich auch mal: Ich hab TV von Anfang an vermieden (und mich geweigert Projekte die damit umgesetzt waren zu betreuen/weiterzuentwickeln). Aus diversen Gründen. Das beginnt schon damit, dass es absurd ist, in einem RDBS _alles_ in XML zu speichern.
Und es endet damit, dass ich größere, langfristig angelegte Projekte nicht von einer Dritthersteller-Extension abhängig mache.
Und ich sag’s nur ungern, aber ich hab recht behalten. 😉

Und was das Jammern über das steigende (!!) Niveau betrifft: schon mal drüber nachgedacht was ‚Enterprise‘ heißt? Als SW-Entwickler der ursprünglich aus der C++ Ecke kommt (the gorgeous c-side of the world, hehe) und jetzt seit 2003 hauptsächlich TYPO3 Projekte umsetzt, finde ich es richtig wohltuend, wie sich die Qualität von PHP (und vielen damit entwickelten Projekten) im Allgemeinen, und die Qualität von TYPO3 im Besonderen entwickelt. Auch wenn ich nicht mit allem glücklich bin (siehe EM in 6.2, wie hat einer (@see mailinglist) darüber so schön geschrieben: optimized to trash).

BastianBalthasarBux am 29. März 2014 um 11:17

Hallo Christian,

ich kann gut Zustimmen, dass FCEs kaum notwendig sind – es gibt gute Alternativen. Da du ja scheinbar sehr von der Ersetzbarkeit von TV überzeugt bist habe ich aber dennoch zwei konkrete Fragen mal direkt an dich:

1. Ein Kunde nutzt irrsinnig gerne Vorlagen, die man in TV einfach als CE erstellt und dann überall hin referenziert, wo man sie haben möchte. Hierfür wird im klassichen T3 aber jeweils ein neues CE benötigt, welches man dann auf „Referenz auf Element X“ konfiguriert (also für jede Referenz ein neuer Datensatz in der tt_content). Bei Vorlagen, die hundertfach wiederverwendet werden, frage ich mich, wieso in einem solchen Fall das klassiche T3 performanter sein soll!

2. Ein Kunde arbeitet gerade an der 12ten Sprache seiner Website. Im klassischen T3 bedeutet das, dass ich mir mangels 4HD-Monitor entweder nur die aktuelle (neue) Sprache anzeigen lasse, oder aber komplett in die Listenansicht wechseln muss. In TV dagegen ist das super einfach zu bedienen, weil jedes Element schon in der Seitenansicht direkt in allen Sprachen sichtbar ist. Noch besser: Will ich ein Element verschieben, dann nutze ich Drag/Drop und … fertig! Im klassischen T3 habe ich (trotz Drag/Drop) hingegen viel Spaß damit dafür zu sorgen, dass die Änderung auch wirklich in allen Sprachen ankommt etc. – schnell mal bei einer Sprache die Spalte umgeändert und dann bei der nächsten, …

Grüße,
Hannes

Hannes am 09. April 2014 um 14:48

Hallo Hannes!
Ich verstehe deine Ansätze und kann gut nachvollziehen was du meinst. Sicherlich gab es in früheren TYPO3-Versionen nicht diese „komfortablen“ Funktionalitäten, wie es sie in TV gab. Aber trotzdem, wozu braucht man die? Es gibt so viele veschiedene herangehensweisen für die redaktionelle arbeit mit TYPO3. So viele Wege die nach „Rom“ führen.
Ich habe nie aktiv TV eingesetzt. Nur immer wieder die verhunzten Projekte von Kunden übernommen und versucht zu retten was zu retten war.
Auch heute noch habe ich Kunden die TV in ihrem TYPO3 läuft und ich merke bei jedem neuen Feature: „Ja, es ist leicht umzusetzen! Aber halt.. Das hat ja Seiteneffekte, die nicht abzuschätzen waren. Oh, es ist doch nicht so umsetzbar“
Und in genau diesen Momenten möchte ich meinen Kunden einen Relaunch schenken. Aber ich tue es nicht, weil es unwirtschaftlich ist.
Es gibt so viele negative Beispiele, so vieles, das eben nicht mit FCEs machbar ist (z.B. Logik in Templates, sowas konnte sogar smarty). Mittlerweile freue ich mich über die neugewonnene Qualität von TYPO3 CMS und vieler Extension wie flux, fluid_content, vhs, dce, backendgrids usw..
Ich möchte es mal so ausdrücken, TV war im Ansatz gut, aber in der Ausführung eher nicht.
Im Grunde genommen möchte ich aber die eben genannten Extensions auch nicht wirklich nutzen, auch wenn sie sehr gut sind. Denn sowohl TV als auch die neuen Helferlein machen eine TYPO3-Installation abhängig von einer Extension. So sollte es einfach nicht sein. Wenn es ein Helferlein gibt, das funktioniert und bei dem sichergestellt ist dass das TYPO3 auch ohne die Helferextensions noch funktioniert, dann bin ich glücklich.
Aber auch hier gibt es eine Antwort, es nennt sich TYPO3 Neos. 😉 I <3 Neos

MfG
Christian

Christian am 09. April 2014 um 23:35

Bzgl. der Performance: In TYPO3/TV können zwar Elemente referenziert werden, aber TYPO3 hat keinen Cache auf CE Basis. D.h. das jedes Content Element pro Seite nochmals gerendert wird. Die Selektion aus der Datenbank bzgl. der Anzahl der Elemente fällt glaub ich nicht ins gewicht. Weshalb angemerkt wurde, dass es langsammer ist, liegt daran:
– Mit TV wird die Datenbank sehr schnell sehr groß. Dies liegt daran, dass die Daten nicht normalisiert und in XML in der Datenbank gespeichert werden. Nutzt man alle Features von TV (z.B. sections etc.) wird das ganze in der DB noch schlimmer.
– Mit TV muss beim Rendern die XML Struktur verarbeitet werden. Dies verarbeiten braucht Zeit, gerade wenn wieder komplexere Funktionen benutzt werden.
– Verschachtelte Strukturn (Grids) mit TV sind ein interessanter Wechesl zwischen Punkt 1 (Selektion auf eine Datenbank, mit großen Datensätzen) und Punkt 2 (Analyse von XML). Die Mischung bzw. das rekusive rendern ist nicht gerade fix.

Dennoch sollte beacht werden. FCE’s in TV sind von Haus aus zu cachen. Wenn das erst einmal im Cache ist (und es im idealfall keine anderen *_INT Objekte auf der Seite liegen), dann ist es genauso schnell wie ohne TV!!! Hinzu kommt, dass mehr Flexibilität immer mehr Zeit benötigt (aufgrund der höheren Komplexität). Das ist Informatikern bekannt… diese Flexibilität sollte aber nicht zu lasten der Vermischung von XML mit einer relationelen Datenbank führen 🙂

PPS: Wir haben TV auch vor 3-4 Jahren viel eingesetzt.
PPPS: Inzwischen nutzen wir es gar nicht mehr.

Grüße,
Tim

Tim Lochmüller am 10. April 2014 um 11:37

Also da muss ich doch herzhaft lachen. Wofür brauchen die zig Tausenden Websites mit TV, die gerade mal auf Hundert Einzelseiten kommen, auf einmal ein hochperformantes System? Die brauchen ein leicht verständliches und auch für Volldummies wartbares Backend. Hier stehen geschätzte 30 Kommentare und keiner kann eine wirkliche Alternative anbieten! Weil es keine gibt und weil das nicht das Ziel von TYPO3 ist. Das Ziel sind ganz klar große und umfangreiche Projekte, dahingehend ist das System nun optimiert bzw. wird optimiert. Ich versteh nicht dass man das nicht klar sagt. TYPO3 ist nun mal ein Enterprise CMS und da halten solche Semiprofis nur auf 😉

Freddy am 10. April 2014 um 23:51

Hallo Freddy, ich verstehe das mit dem „da muss ich doch herzhaft lachen“ und dem „Semiprofis“ nicht. Wie du siehst habe ich nur eine Theamtik betrachtet, weshalb mein Beitrag mit einem „Bzgl. der Performance:“ begonnen hat. Zudem wiederspricht sich der Anfang „1000 Webseiten die keine Performance brauchen“ mit dem Ende „Ziel ist es große Seiten zu bauen“. Aber gerne greife ich deine sachlichen Punkte nochmal auf…

Ich gebe dir Rechte, das viele Seiten keine Performance „brauchen“. Seit dem Google Ladezeit in die Bewertung der Seiten mit aufgenommen haben, schreien auch die „kleinen“ immer mehr dannach schnell unterwegs zu sein. Zudem sollte es hier nicht darum geben, „wir machen große Seiten schnell“ und „kleine langsamm“. Wenn man die großen Seiten doch schnell bekommt, sollten die kleine doch von Haus aus noch schneller sein, oder?

Gerne zeige ich Alternativen auf. Dazu würde ich gerne deine Aussage in 3 Teile aufgliedern: Ausgabe, Integration, Benutzung (Redakteur). Wir haben bei uns die Benutzung von TV evaluiert und sind auch auf diesem Weg da ran gegangen (ein wenig umfangreicher, aber im groben so ähnlich). Fangen wir mal vorn an…

Ausgabe: Die Ausgabe mit TV unterscheidet sich natürlich nicht von einer anderen. Da TV jedoch als eine „template“-Engine betrachtet wird, sollte man prüfen wie gut diese für die Ausgabe zu benutzen ist. Vergleicht man diese mit anderen, ist die Struktur nicht mit moderner Software zu vergleichen. Beispiel: TV (DS = Model, TO = View, Extension selbst [Plugin nicht änderbar] => Controller). Das TemplaObject selbst kann keine Kontrollstruktur für die Ausgabe enthalten, weshalb dies mit der Datenstruktur gemischt wird (TS). Aus Programmierer-Sicht ist das Handling eher fraglich. Als Alternative zur Ausgabe sehe ich Fluid als eine gute und zukunftssicher Alternative. Fluid ersetzt die „View“ von TV und unterstützt Kontroll-Strukturen für die Ausgabe und zahlreiche weitere Funktionen (ähnlich wie Smarty). Die Datenhaltung (DS) brauche ich ja nicht nochmals erläutern. Ich bitte die Punkt aus dem Performance-Kommentar von mir zu extrahieren.

Integration: Hier hat TV die Vorteile, gerade was den Einstieg angeht. Es wird nur ein Template benötigt und es lässt sich im Backend ein neues Inhaltselement zusammen stellen. Dies ist klar ein Vorteil von TV. Wenn wir in TV trennen zwischen Grids und normalen FCEs, so können wir die Grids inzwischen in TYPO3 mit Backend-Layouts und Gridelements umsetzen. Dabei ist zu bedenken…. Gridelements ist ausschließlich zum erhöhen der Flexibilität zu betrachten. Wenn ein Redakteur 100x die gleiche Gridstruktur anleget, sollte dies in einem Backend-Layout abstrahiert werden. Die Grids von Gridelement sind einmalig einzurichten und es geht genauso schnell wie in TV (Alternative bzw. Ergänzung zur View). Bei den normalen FCEs ist die Alternative normale Content-Elemente mit TYPO3 bauen. Dieser Gedanke entspricht dem Grundgedanken der Core Struktur (TCA, rendering, tt_content) ist aber bei der Integration ein wenig umfangreicher als ein FCE zusammenklicken (Alternative zu dem Model). Wenn jedoch mal 1-2 erstellt wurden und man sich ein paar Helper programmiert, ist das deutlich fixer (Ich brauche z.B. nur ein Model anlegen und habe direkt ein neues Content Element). BTW… ganz nebenbei bekommt man noch einen Controller dazu, in dem der Kontrollfluss und weitere Komplexität untergerbacht werden kann (zuvor nicht möglich gewesen oder via TS irgendwie in die DS reingedrahtet).

Benutzung: In der Benutzung ist die Kombination „Gridelements, BE-Layouts, Content-Element“ genauso zu betrachten wie „TV mit Grids und FCE + Content Element“. Optisch kann man sich nun jetzt streiten (das eine hat ein wenig mehr padding, das andere ist ein wenig heller etc.), aber ich bin was das angeht kein Usability-Experte.

Fazit: Das Ziel ist ja auch große Projekte zu machen, weshalb ja auch „Enterprise“ auf der TYPO3-Fahne steht. Im Agenturgeschäfft muss der Erstellungs-Prozzes der Webseite in TYPO3 jeoch standardisiert werden, sodass nicht jeder Mitarbeiter es anderes baut. Vor 3-4 Jahren war TV unser Standard, weil es keine Alternativen gab. Dies hat sich inzwischen geändert (aufgrund der Punkte oben im Kommentar). Gerade wenn die Projekte groß sind/werden bekommen Punkt wie Wartbarkeit, Wiederverwendbarkeit, saubere Datenhaltung, schnellere Auslieferung eine immer größere Bedeutung.

Wenn du weitere Argumente aufzeigst, wäre ich sehr dankbar! Ggf. hilft es vielen Integratoren sich für oder gegen TV zu entscheiden.

Tim Lochmüller am 11. April 2014 um 08:30

Hi Tim, das Lachen bezog sich nicht auf deinen Kommentar, sondern auf den ganzen Baum. Wer TV nicht eingesetzt und verstanden hat, sollte sich meiner Meinung nach aus der Diskussion raushalten. Es sind immer wieder die gleichen Aussagen, ich hab noch nie ein FCE gebraucht, was soll das ganze TV-Konstrukt usw. Ich kann auch zig Beispiele auflisten, wo wir Seiten übernommen haben, egal was für eine Template-Engine, die waren jenseits von gut und böse. Für mich war und ist der große Vorteil von TYPO3 die Flexibilität und die hat TV nunmal perfekt umgesetzt. Bevor ich meine Redakteure mit irgendwelchen Verenkungen mittels Layout und Rahmenfeld zu tollen Inhaltselementen verhelfe macht man ein FCE und gut.
Das die Zeit von TV zu Ende ist, ist glaub ich jeden klar, aber wo sind die Alternativen und wie kann man bestehende Systeme updaten. Ich hab Systeme die laufen seit 2004 auf TYPO3 und TV! Aktualisiert und jeweils technisch auf dem neuesten Stand. Natürlich ist die Performance wichtig und manche Pseudo Webdesigner werden auch ohne TV TYPO3 Seiten machen, aber mir war immer der Redakteur wichtig. Ob man nun für das System ein Guru sein muss, oder ob ein dressierter Affe das genau so gut umsetzen könnte, sollte für den Kunden egal sein. Er muss mit dem System gut arbeiten können, alles andere ist unwichtig. Die Distributionen im 6.2 und das Bootstrap Package schauen da schon recht gut aus. Es gibt auch einen Ansatz mit Themes, auch da tut sich einiges. Und wie du ja selbst weißt, es gibt gerade für simple Projekte sehr gute Systeme wie WordPress. Zusammenfassend Finger weg von TV bei neuen Projekten, beten für die alten, das sich doch jemand findet der TV updatet, und hoffen dass die Updates auf 6.2 vielleicht schon in den nächsten Wochen klappen werden. Wenn nicht, wirds wohl ein forke werden…

Freddy am 11. April 2014 um 12:10

Hallo Freddy, vielen Dank für Deinen konstruktiven Kommentar. Du sprichst genau das Problem an.
Die meisten Kommentare sind vollkommen losgelöst von der relevanten Realität in vielen Unternehmen.
Das sind Prinzipiendiskussionen – teils fast getrieben von der Sehnsucht der „echten Profis“, endlich die ganzen Halbprofessionellen loszuwerden und mit Typo3 in einer „höheren Liga“ zu spielen.
Ich bin auch sehr traurig dass die Entwicklung anscheinend eher typisch deutsch vorangetrieben wird. Der Erfolg von Typo3 ist aber in nicht unerheblichem Maß durch die große Community entstanden und nicht dem kleinen Kreis der wirklich kompetenten Nutzer. Das hat die Verbreitung gebracht.
Ich habe gerade eine kleinere Seite mehrsprachig in 6.1. und musste feststellen, wie sehr ich die einfache Abbildung im Backend vermisse, die ich durch TV gewohnt war. Es fühlt sich im Handling wie ein Rückschritt an.
Ich habe eine sehr komplexe alte Seite mit TV – die kann ein Redakteur sehr schnell im Backend begreifen und nachvollziehen.
FCEs mit vorbereiteten Auswahlmöglichkeit, machen die Pflege einfach … hinsichtlich Gestaltung ist es einfach simple neue FCE’s hinzuzufügen.
Selbst in der kleinen Site jetzt vermisse ich die Flexibilität und fühle mich regelrecht gefangen in dem Korsett, das nur mit vergleichbar hohem Aufwand zu erweitern ist, der sich für das Projekt nicht lohnt.
Ich will nicht an TV festhalten und habe begriffen, dass es keinen Sinn mehr macht.
Was mich aber pessimistisch stimmt, ist die Fixierung auf die eher technische Seite. Im Alltag und für den Endkunden, die Designer und Redakteure ist das aber oft nur ein Aspekt und die Abhängigkeit von den Programmierern auch für kleinste Gestaltungswünsche oftmals hinderlich.
Im Ergebnis entstehen zahllose optisch fast austauschbare Seiten – einfach weil es sonst zu aufwändig wird.
Im Endeffekt werden die Websites in der Wahnehmung nicht nach technischer Finesse und schönem Code beurteilt, sondern nach Optik und Usability.
Ich bin immer wieder erstaunt, wie altbacken und unprofessionell manche Websites von echten Profis aussehen, die die Hände über den Kopf zusammenschlagen würden, wenn sie andere Seiten beurteilen, die schick aussehen aber womöglich grauenvollen Code haben.
Natürlich gibt es viele Aspekte und ich möchte nicht in Frage stellen, dass ein vernünftiges technisches Fundament essenziell ist. Nur bleibt eine Website letztendlich ein Kommunikationwerkzeug. Und für die Kunden steht immer die Kommunikation im Vordergrund und im Focus stehen Flexibilität und Aufwand – alles Andere wird eher als selbstverständlich betrachtet.
Wenn ich eine super aufgesetzte Website anbiete, der Kunde sich aber begrenzt fühlt und neidisch auf eine Konkurenzsite schaut, die einfach mehr gestalterische Spielräume hat und plump gesagt „toller aussieht“ … nützt mir das ganze WIssen über das gute Fundament, Updatesicherheit, Performance etc. garnichts (es sei denn, ich habe es mit so einem großen Kunden zu tun, dass meine Ansprechpartner über Fachkompetenz verfügen)

ralf am 11. April 2014 um 12:53

Nochmal zu den Alternativen:
flux + fluid_content + vhs
oder
dce + backendgrids

Ganz einfach…

MfG
Christian

Christian am 13. April 2014 um 12:30

Was Ihr alle irgendwie noch nicht begriffen habt ist die Wartbarkeit von Code. Das ist ein Mangel den ich immer wieder bei TV verfechtern merke.
Mir ist es wurst was der ein oder andere Denkt, aber fakt ist das ich nicht eine Seite mit TV kenne die gut wart- und erweiterbar ist. Was nützt es dem Kunden wenn er tolle FCEs selbst nutzen kann und alles total Easy erscheint, man ihm als Programmierer aber sagen muss das durch die schlechte qualität des Codes eine Wartung oder Erweiterungen teurer sind als wenn man es von Anfang an gleich ordentlich gemacht hätte.
Es gibt keine Kunden die sowas toll finden. Denn im Nachhinein mehr zahlen zu müssen bedeutet ständig doppelt und dreifach zahlen. Absolut unwirtschaftlich und wer sowas macht, macht eine Menge falsch…

Christian am 13. April 2014 um 12:40

Der einzige der hier nicht begreift, bist Du! Der Code ist dem Kunden völlig egal, Du und nur Du bist dafür verantwortlich das alles läuft. Dem Kunden gegenüber rumzujammern das der Code schlecht ist, ist erbärmlich. Deine Aufgabe ist es eine Lösung zu finden und nicht hinterher zu behaupten, anders wäre alles besser. Wenn man ein System wie TYPO3 einsetzt muss man halt mit allen Varianten vertraut sein und auch für alles eine Lösung haben. Denn Du machst mit solchen Aktionen und Aussagen das System schlecht, dabei wäre es Deine Aufgabe eine akzeptable Lösung zu finden. Ein wirklich guter Programmierer findet immer eine Lösung, denn im Grunde genommen sind es immer nur Datensätze in einer Tabelle.
TV wurde von vielen eingesetzt, nicht nur von Halbwissenden. Und stell Dir vor, jetzt sollen auch noch Themes kommen, diese können dann nicht nur von Halbwissenden, sondern auch von Unwissenden eingesetzt werden. Ohne Rücksicht auf die Qualität des Codes! Ob TYPO3 das überleben wird! 😉

Freddy am 13. April 2014 um 13:28

Danke das du uns erklärst wie wir unseren Job zu machen haben.

Udo Kier am 13. April 2014 um 22:56

Bitte, mach ich doch gerne! Bei Fragen einfach melden 😉

Freddy am 14. April 2014 um 09:11

Freddy, ernsthaft.. der kunde bekommt was er bezahlt.. und wenn er trotz eingehender Beratung, denn das ist unsere Aufgabe neben der Programmierung, eine schlechtere aber dafür günstigere Lösung verlangt, dann wird er natürlich im nachhinein aufgrund der schlechteren Lösung bei Features oder Weiterentwicklung drauf zahlen müssen. Niemand schenkt irgendwem etwas. Wäre ja auch unwirtschaftlich. Das scheinst du noch nicht begriffen zu haben. Das selbe gilt übrigens bei seiten die von einer anderen Agentur übernommen werden und die ebenfalls schlecht gemacht wurden.

MfG
Christian

Christian am 14. April 2014 um 10:39

Da geb ich Dir recht, ich versteh da was nicht. Günstig ist schlecht und wenn eine andere Agentur die Seite mit einem Dir nicht zusagenden System gemacht hat, ist das auch schlecht?!
Ich hab mit TYPO3 schon so manches gemacht, egal ob selbst gestartet oder übernommen. Egal ob TV, Static Template, Automaketemplate, Fluid oder was auch immer und der Kunde war zufrieden und fast immer war eine günstige Lösung möglich. Nicht weil ich dafür den Stundensatz gesenkt habe, sondern weil es mit TYPO3 immer Lösungen gibt. Mit TYPO3 gibt es nur eine Einschränkung, das Können des Umsetzers. Und da geb ich Dir recht, da sind gewaltige Defizite vorhanden. Vielleicht öffnest Du Dich auch dem gesamten TYPO3 Universum, glaub mir, das macht das Arbeiten erheblich angenehmer und mittelfristig auch deutlich besser bezahlt.

Freddy am 14. April 2014 um 11:08

Es ist ein sehr verbreitetes Verhalten bei Designern und Programmierern bei Kunden derart aufzutreten. Die eigenen Maßstäbe anzulegen und erst einmal alles schlecht zu reden.
Das ist für Kunden prinzipiell irritierend und wirft ein schlechtes Licht auf alle betreffenden. Erstens kann es der Kunde nicht wirklich beurteilen und wird (aus Erfahrung) vermuten, es mit einem „Besserwisser“ zu tun zu haben, der bereits im Vorfeld nach Entschuldigungen sucht, warum die bevorstehenden Arbeiten so aufwändig/schwierig/teuer werden – schuld sind natürlich die anderen…
Statt Vertrauensverhältnis wird so eher eine distanzierte kritische Kundenbeziehung entstehen.
Selbst wenn es wirklich so sein sollte, dass der Vorgänger schlampig war – für den Kunden ist es eine irritierende Erkenntnis und seine Angst davor, dass der nächste Programmierer dann wieder dasselbe sagen wird wächst nur.
Ich gebe Christian recht. Statt zu jammern, nach bestem Wissen und Gewissen das beste daraus machen. Und so professionell und neutral wie möglich.
Diese ganze Zerrissenheit ist doch genau das, was die Kunden ängstigt und weshalb sie im Zweifel dann doch lieber zu den ganz großen Playern gehen.
Wird Typo3 zu abgehoben und das Image entsteht, dass es ein schwieriges Enterprise System ist, das nur schwer zu beherrschen ist, wird das Typo3 nicht nutzen auf Dauer. Dann wird es ein kleiner Kreis an leitungsfähigen Agenturen sein, die die hochwertigen Sites betreuen und die mittleren und kleinen werden sich anderweitig nach Lösungen umschauen, die sie weniger verunsichern.
In den letzten Monaten habe ich es schon immer öfter gehört, wie Leute in unternehmen beim Stichwort Typo3 eher abwinken.

Ralf am 14. April 2014 um 15:11

In den letzten Monaten? So lange wie ich Typo3 implementiert hatte(ca. ab 4.3 bis vor einem halben Jahr) haben die Leute immer abgewunken und gemeint, dass Typo3 hässlich, umständlich, hohe Lernkurve und veraltet sei. Das muss man als Typo3-Implementierer einfach abkönnen. Mann kann es den Leuten ja nicht unbedingtverdenken. Wenn man mal das schöne Backend von WordPress gesehen hat, graust es einem ja förmlich, wenn man sich in das Typo3-Backend einloggt. Auch wenn WordPress natürlich einen deutlich geringeren Funktionsumfang out of the Box bietet.
Die angesprochene „Zerissenheit“ wird eher durch die Zweigleisigkeit von Typo3 (Neos und CMS) erzeugt.

ewfwefewfew am 15. April 2014 um 01:25

Hallo zusammen

Meine Erfahrungen und meine Meinung dazu:

TV: War früher schon, einfach und relativ schnell. Ist aber klar unsauber da alles als XML in der DB landet. Da es nicht mehr aktiv weiter entwickelt wird ist für uns klar dass wir das nicht weiter einsetzen werden. Einige Projekte werden wir wohl mit dem compat-release (weiss jemand wann der kommt?) patchen, da der Kunde kein Geld für eine Neuentwicklung spricht.

Fedext (resp. Fluid Powered Typo3): Spannende Extensions, schön zum Entwickeln mit all den Viewhelpern. Haben wir ein Paar mal eingesetzt. Das grosse Manko dort ist die Stabilität resp. die breaking-changes. Meine Erfahrung dort ist, dass man meist die eingesparte Zeit wieder durch die unsaubere Dokumentation und verändertes Markup wieder verliert.

Core (Extbase/Fluid): Technisch sicher stabil und die sauberste und flexibelste Lösung. Was mich dort aber stört ist der Umstand, dass das anlegen eines einfachen FCE-ähnlichen Containers (z.b Ein Slider mit verschiedenen Slides) unglaublich lange dauert. Ich teste aktuell gerade mit 6.2. Dort ist ja beispielsweise das carousel-fce dabei (vgl. hier https://www.evernote.com/shard/s59/sh/6d64b3a8-dfd0-48af-a374-4ebf62ba9c5a/6aa9e60f8da50a072371bb53b8d7fd9c). Allein für ein solches FCE muss ich 9 Files bearbeiten (TS, TCA, Templates, usw.). Andere CMS sind da bedeutend schneller mit Core-Mitteln. Vielleicht zeigt sich ja einer der Core-Enthusiasten bereit für einen E-Mail-Austausch mit best practices wie man darin schneller wird.

Gridelements und weiteres: Noch nie produktiv eingesetzt. Ich frage mich ob man damit nicht einfach in eine weitere unnötige Abhängigkeit kommt.

Mein Fazit ist, dass es im Moment keine zufriedenstellende Lösung gibt. Für kleine Agenturen sind aus meiner Sicht die Faktoren Entwicklungszeit, Stabilität, und Wartbarkeit zentral. Wann immer möglich setze ich dabei auf etwas das im Core integriert ist. Reicht der Core aber nicht aus müssen drittextensions herangezogen werden. Diese sind jedoch immer ein wenig mit Roulette zu vergleichen, da man nie weiss wie die Entwicklung dort weiter geht.

Aus meiner Sicht ist das Templating und das erstellen von Contentelementen ein zentraler Teil eines CMS. Der Fakt dass sich ein grosser Teil der Community mit den Core-Mitteln nicht zurecht findet, finde ich schon ziemlich beunruhigend.

PS: Eine Frage an all die die sagen FCE braucht es nicht. Wie meint ihr das? setzt ihr schlicht keine custom elemente ein (z.b. mit sections wie mein obiger screenshot)? oder nehmt ihr dazu einfach extbase/fluid?

Michael am 15. April 2014 um 16:00

Leute nehmt es mir nicht übel, aber eigentlich kommen wir alle sehr weit vom Thema ab. Deshalb klink ich mich an dieser stelle mal aus.

MfG
Christian

Christian am 15. April 2014 um 22:23

Aus meiner Sicht ist das Templating und das erstellen von Contentelementen ein zentraler Teil eines CMS. Der Fakt dass sich ein grosser Teil der Community mit den Core-Mitteln nicht zurecht findet, finde ich schon ziemlich beunruhigend.
PS: Eine Frage an all die die sagen FCE braucht es nicht. Wie meint ihr das? setzt ihr schlicht keine custom elemente ein (z.b. mit sections wie mein obiger screenshot)? oder nehmt ihr dazu einfach extbase/fluid?

Das Core Team ist sich der Notwendigkeit von FCEs bewusst. Allerdings ist die technische Implementierung ein Trilemma aus verschiedenen Herangehensweisen, welche alle diverse Probleme mit sich bringen. Oder anders ausgedrückt: Es gibt keine „gute“ technische Lösung um beliebig strukturierte Elemente zu ermöglichen.

Deswegen gibt es diverse Extensions, welche das Problem auf verschiedene Arten angehen: gridelements, dce, fedext.net, custom extension, etc.

Philipp Gampe am 16. April 2014 um 19:59

Wenn eine Extension so lange wie TemplaVoilá gepflegt und immer weiter verbessert wurde, dazu so großen Anklang fand, war früher mal der Weg zu einer Systemextension nicht weit. Ich werde sauer, wenn ich nach ca. 10 Jahren Arbeit, um nicht zu sagen: Maloche, mit TYPO3 Stimmen aus einer „Community“ zu hören bekomme, die sich über „User mit Halbwissen“ auslassen, weil Sie Ihre Zeit nicht auch noch im meterlangen TYPO-Script verlieren wollten, solange es gute Alternativen gab.

Wer von den TemplaVoilá-Kritikern hat denn die Extension wirklich verwendet – wen von denen ist denn wirklich bewußt, wie gut das Handling von Inhaltselementen damit ist? Die Attraktivität von TYPO3 ohne TV verliert immens.

Wenn nicht in den Jahren etliche Projekte mit TemplaVoilá enstanden wären, wollte man sich nur zu gerne diesem Kindergarten entziehen. Dieser Fisch stinkt vom Kopf her – nicht die Community ist gemeint, sondern die Core-Entwickler, die gerade das Kind mit dem Bade auskippen.

Wenn schon das CMS nur noch von sich selbst ernannten Vollprofis ausschließlich in „Enterprise“-Formaten anwendbar sein soll – dann doch gleich mit der Konsequenz, das CMS auch zu verkaufen. Ja – ich weiß, dass das in die Hose ginge, den die OpenSource-Wurzeln von TYPO3 sind zu tief.

Ich verstehe Herrn Tolliev nur zu gut, dass er sich mit den gegenwärtigen Änderungen in der Gesinnung der „Herren von TYPO3“ nicht anfreunden will – denn hier entsteht mehr und mehr eine Master-Community in der Anwender-Community, die versucht die Richtung vorzugeben.

Peter am 17. April 2014 um 19:04

Du gehst von der Prämisse aus, das Templavoila mal gut war, was allerdings falsch ist. Templavoila war schon immer murks. Angefangen vom XML Datenbankmurks bis zu den ständigen Kompatibilitätsproblemen. Kein Wunder das sich Entwickler nach etwas besserem umsehen.

fzkfzj am 18. April 2014 um 11:31

Ich beobachte nun TYPO3 seit mehr als einem Jahrzehnt und habe auch schon Diverses damit umgesetzt. Spätestens seit dem Ausscheiden von Kasper Skarhoj hat sich TYPO3 eindeutig in eine sehr finanz-orientierte Richtung bewegt, welche von ein paar Köpfen vorgegeben wird … zum Wohl von […]
Dies bestätigt sich für mich durch diverse Posts in diesem Blogpost.
Schade um dieses ehemals gigantische Projekt.

Alexander am 18. April 2014 um 15:30

@Peter
Ich könnte es total verstehen, dass die Entwickler sich nach „etwas Besserem“ umsehen – nur verstehe ich nicht, warum sie die Bedürfnisse der Anwender vollkommen ignorieren, die sich ja gerade durch den massenhaften Einsatz der so bekannt problematischen TV Extension seit Jahren deutlich manifestiert.
Nachdem ich die letzte Website in einer aktuellen Version ohne TV realisieren musste, fühle ich mich jedes Mal, wenn ich im Backend etwas einpflege auf Jahre zurückgeworfen und kann es garnicht fassen-
Es fühlt sich wirklich ganz praktisch wie Rückschritt an.
Und zwar in vielen Ebenen. Und ich kann versichern, dass ich prinzipiell immer sehr offen bin für neue Wege.

Ralf am 23. April 2014 um 19:35

TemplaVoila war für mich schon immer grauenhaft und ist mittlerweile schlicht veraltet. Punkt.

Eine zeitgemässe Alternative ist z.B. http://fluidtypo3.org

Thomas am 24. April 2014 um 10:43

Natürlich kann man einfach einen Punkt machen. Basta.
– aber das ändert nichts an dem Vakuum, der mangelnden Alternative.
Hinsichtlich der fluid extension die Du vorgeschlagen hast anbei das Zitat eines Typo3 Entwicklers mit 11 Jahren Erfahrung, der begeistert davon ist aber auch zugibt dass es keine brauchbaren Tutorials gibt, er trotz direkter Unterstützung der Entwickler unglaublich viel Zeit brauchte und diverse Rückschläge hatte, es überhaupt hinzubekommen…

„The FluidTYPO3 ecosystem is really, really huge and complex. Unfortunately, I have not been able to find a compact, simple and understandable documentation that gives a comprehensive overview across all the extensions and provides a conclusive step-by-step introduction. I really had a hard time finding the entrance — despite my 10+ years as a TYPO3 developer. Without the initial instructions from Jonas I’d probably have given up pretty soon (thanks again for that, Jonas!)“

ralf am 24. April 2014 um 14:33

Hallo Zusammen,
ich möchte auch mal zu diesem Thema (TV) etwas sagen, weil ich diese Diskussion um das Für und Wieder im Templating sehr „merkwürdig“ und größtenteils unnütz empfinde.

Ich arbeite seit über 10 Jahren mit TYPO3 (seit den Versionen 3.x), würde mich nicht als Experten/Nerd sondern ambitionierten Anwender/Anbieter/Umsetzer bezeichnen und wundere mich um die sehr heftig geführten Ego-Diskussionen um TV.

Dass es kaum jemanden auffällt, dass TV mit zu den absolut beliebtesten Extension gehörte, findet kaum Berücksichtigung und es fragt sich kaum wer, WARUM das so war. Das es wahrscheinlich seine LOGISCHEN Gründe gehabt haben wird, geht aus keiner der unnötigen und kontroversen „Kriegsspielchen“ hervor. Wieso nicht auf die Bedürfnisse der Anwender (Integratoren, Redakteure) eingegangen wird und stattdessen die Ego’s der Entwickler genährt werden, ist sehr schade. Argumente wie „Ich habe TV immer schon gehasst und nicht verwendet“ sagen lediglich aus, dass da wer nicht mit TV umgehen konnte oder es nicht mochte, nicht mehr.
Es soll ja auch niemand dazu gezwungen werden, irgendwas nutzen zu müssen. Ich habe Websites mit verschiedenen Techniken umgesetzt und finde bzw. WEIß, dass TV mir immer sehr viel Arbeitszeit erspart hat UND den Komfort auf Integrations- und Redaktionsebene deutlich erhöht hat. Das werden zig Tausende andere Webdesigner und -entwickler genauso gesehen haben, was dann auch LOGISCH an den Zahlen der Installationen leicht abzulesen ist/war, denn aus Spaß wird sich das niemand angetan haben, sich mit Templavoila zu beschäftigen!?

Mit Fluid ist kein Mensch ohne Programmierbackground in der Lage, ein externes Design in Version 6.2 einzubauen. Klar kann man das vorhandene Bootstrap anpassen, doch das erklärt mal einen externen Designer, der nur HTML-Designs mit Photoshop erstellt…. und nichts über TYPO3 weiß.
Mit TV habe ich denen sagen können, macht eine Design mit DIV-Containern und fertig. Das dann mal eben gemapped und erledigt. Und heute?

Es kommt mir oft wie in einem Kindergarten für halb Erwachsene vor, wenn solch flache Argumente ausgetauscht (sich gegenseitig um die Ohren gehauen, passt besser) werden, wie z. B. dass XML-Code in einer Extension ja überhaupt nicht ginge….
Warum das? Ist mir doch (primär) völlig egal, in welcher Form die Daten gespeichert werden, HAUPTSACHE es funktioniert und man steigt in einer angemessenen Zeitspanne durch UND kann auch die Redakteure „mitnehmen“ und begeistern. Das sehen vor allem auch meine Kunden so, denen ist das noch gleichgültiger, Hauptsache sie haben einen gewissen Investitionsschutz, sprich ihre Site läuft möglichst lange und kann upgedated werden.

Das einfache und schnelle Mappen von Containern (div’s, etc.) fand ich ein unschlagbar geiles Feature. Das Rumschieben von FCE’s fanden alle Redakteure/Kunden auch immer völlig gut!

Natürlich kann ich auch ohne TV eine Website erstellen, doch ich hampel damit viel länger rum und es macht auch keinen wirklichen Spaß. Davon abgesehen, dass anderen ambitionierten Interessenten mal näher zu bringen. Die Integration von extern gelieferten Designs (a la Photoshop z. B.) ist definitiv heute NICHT leichter und schneller, als es mit TV möglich war.

Was mich jedoch wirklich ärgert ist NICHT, dass der eine für TV ist und der andere lieber „native“ arbeitet, sondern das hier UNNÖTIG die früher vorhandene VIELFALT abgeschnitten wurde. Für alles mögliche (und unmögliche) gibt es oft mehrere Extensions… nur bei den wichtigen/nützlichen/interessanten wird gegen so eine Vielfalt aus mir nicht nachvollziehenden Gründen gewettert. Wenn einige Entwickler (waren das überhaupt Entwickler?) nicht so unnötig herb mit Tolleiv Nietsch umgegangen wären, hätte er es vielleicht auch auf Version 6.2 angepasst und ganz sicher die Community und das Projekt TYPO3 BEREICHERT. Schade das es von vielen nicht erkannt und ignoriert wird. Abgesehen davon, dass ich mich in Grund und Boden schämen würde, so wie sein großartiger Einsatz von diesen Dummköpfen mit Füßen getreten wurde. 🙁

Ich finde das sehr schade und glaube auch nicht, dass es dem Projekt TYPO3 insgesamt irgendwelche Vorteile eingebracht hätte. Wer viele TV basierte Websites schon betreut, wird sich „freuen“, seinen Kunden erklären zu müssen, warum die jetzt bald ein neues Design brauchen werden und warum die Updates nun nicht mehr laufen… 🙁
Toll. Die theoretische Diskussion darüber, was denn nun technisch moderner/besser ist, ist vollständig an praktische Aufgabenstellungen vorbei.

Als Fachinformatiker, der seit 25 Jahren programmiert und sich schon etwas mit verschiedenen Systemen auskennt, glaube ich so etwas auch einigermaßen objektiv beurteilen zu können.

MIR was es schon immer egal, ob ich einen Mercedes, Audi oder BMW fahre, Hauptsache er fährt vernünftig oder analog dazu, ob ich in C, Pasacal, Java, PHP oder sonst was programmiere, WENN es für meinen Job/Projekt das geeignete Werkzeug ist.
Es zu seiner persönlichen „Geschichte“ zu machen, raubt nur unnötig Zeit und Energie.

Ich würde es begrüßen, wenn es sogar NOCH MEHR Alternativen in TYPO3 gäbe, um extern entwickelte Designs in T3 integrieren zu können, oder eben nur eine Möglichkeit, die dann aber auch wirklich den Begriff „Enterprise“ verdient hat. Doch viele in der Szene verstehen „Enterprise“ als etwas, dass maximal kompliziert, anstatt maximal flexibel sein muss.

Naja…. vielleicht wird das alles auch noch mal Erwachsener… und runder.

Ich finde es bezeichnend, dass es für alle anderen CMS hunderte kostenlose oder zumindest bezahlbare Designs auf dem Markt gibt, NUR für das angeblich beste und einzige Enterprise System gibt es fast nichts (mehr). Darauf werde ich immer wieder mal in Kundengesprächen drauf hingewiesen und jedesmal kann ich Klimmzüge machen, um dem Kunden das einigermaßen erklären zu können. Klar sage ich ihm, dass TYPO3 kein Baukastensystem mit vorgefertigten Designs/Templates ist… nur wenn der dann fragt „Achso, also ist WordPress oder Drupal oder Joomla ein Baukastensystem…?“, muss ich die Wahrheit sagen, dass es unter TYPO3 aufwendiger ist ein externes Design einzubinden.

Mit TV gab es noch solche Sachen wie if20 (auch wenn die sich zerstritten haben) oder WEC ….
und heute?

Heute „darf“ ich neben TS, HTML, CSS, JS auch noch Fluid, Gridelements, DCE und was weiß ich noch alles beherrschen…. nur um ein Design zu integrieren. Vorher mit TV brauchte es ein paar Zeilen TS und schon konnte man ein Design integrieren/mappen.
Hhmm… meine nur ich, dass es schon ziemlich heftig ist und sicher viele potenziell interessierte Menschen in die Flucht schlagen wird?

Ich kritisiere nicht die Entwickler, sondern lediglich die Leute, welche an der Praxis vorbei gegen Vielfalt argumentieren. Verkauft mal der Lufthansa (nur EIN Beispiel) mit einem duzend großer Installationen, dass TV nicht mehr unterstützt wird und neue Templates entwickelt werden müssen, die dann GENAUSO aussehen werden, wie zuvor….
Damit haben diese Leute, die sich so sehr für das Verschwinden von TV eingesetzt haben, DEFINITIV nichts am Hut. Denn sonst hätten sie niemals das von sich gegeben, was sie von sich gegeben haben.

Ich bin mal gespannt, wie sich das alles auf Auftraggeber/Kunden/Argenturen noch auswirken wird.

Ich finde es nicht machbar, einem Kunden, der einen Audi gekauft hat, nach ein paar Jahren zu sagen, dass es dieses mal keine normale Inspektion mehr mit Oilwechsel, neuen Zündkerzen, neuen Bremsen mehr sein wird, sondern dass diese mal auch noch ein neuer UND anderer Motortyp eingebaut werden muss…. OBWOHL der alte Motor noch tadellos lief. Da kann man dann noch so viele tolle Argumente haben („ist moderner, schöner, schneller, etc“)… das Auto kauft sicher niemand noch mal neu…

Schön dass sich noch ein neues Team gefunden hat, welches das hier genannte auch so sieht wie ich und hunderte andere Leute auch und Templavoila auch für 6.2 lauffähig machen. 🙂
Danke Euch für diesen sinnvollen Einsatz.

Ich wünsche mir für Euch, dass Eure Arbeit eine höhere Wertschätzung erhält, als sie dem Entwickler davor zuteil wurde.

ALLEN ein schönes sonniges Wochenende und noch viel Freunde mit Eure Arbeit.

Herzliche Grüße,
von Ralf

Ralf Becker am 31. Mai 2014 um 16:46

Nun ja, die meisten wollen nun mal mehr haben, als nur „hauptsache es funktioniert“. Es ist ja schön, dass der XML-Haufen anfangs irgendwie funktioniert, aber damit es auch auf lange Zeit auch skaliert und wartbar bleibt, muss eine ordentliche und durchdachte Architektur her. Man sollte da schon ein Auge darauf haben, wie es unter der Motorhaube aussieht, um mal beim Beispiel zu bleiben.

Boris Becker am 02. Juni 2014 um 23:44

Bei den Fakten geblieben ist es schlicht so, dass wegen der tollen und professionellen Neukonzeption und über Board werfen alter funktionierender Extensions (wie z. B. TV), nun tausende Firmen ihre Websites nicht updaten können, weil sie das nicht wegen vorherigen Einsatz von TV können.

Alles andere ist doch Geschmacksache. Jemanden zu erklären, warum ein Auto Neukauf besser ist, obwohl noch der alten Wagen noch gut läuft… 😉

Wem nützt der Hinweis, dass die zig tausend Firmen, welche auf TV gesetzt haben, auf’s falsche Pferd gesetzt haben? Und dies nicht mal aus technischen, sondern aus politischen Gründen. Das tolle Verhalten mancher „Reformer“ gegenüber dem TV-Entwickler spricht da ja Bände. Das die selbe Häme auch an unzählige TYPO3-Kunden geht, scheint kaum wen zu stören.

Zumindest weiß ich schon, dass einige darüber nachdenken, bei einem erzwungenen Relaunch auf ein anderes CMS zu setzen, weil sie Angst haben, dass in ein paar Jahren wieder alles neu gemacht werden muss. Investitionsschutz geht in den Augen vieler eben ganz anders… Diese Leute führen eben NICHT einen Glaubenskrieg, sondern suchen verlässliche Partner. Ob da ein Mercedes-Stern oder ein VW-Zeichen auf der Haube pappt, ist denen egal.

„eine ordentliche und durchdachte Architektur“.
Solange, bis wieder eine neue Technik durchsetzt wird und das Alte erneut über Board fliegt…
Passiert ja immer wieder… nicht nur in der TYPO3-Welt 😉

Ok, hast ja Recht… darüber zu diskutieren ist obsolet, zumal eh keine praxisrelevanten Hinweise/Tipps dabei rum kommen. Es kann nur dem Kunden VERKAUFT werden, warum er ein Redesign braucht. Die Vollblutverkäufer an der TYPO3-Front freuen sich, weil sie Umsätze generieren können. Ich gehöre nicht zu denen, welchen es leicht fällt, diesen Leuten zu erklären, warum die ein Relaunch finanzieren müssen, ohne dafür irgendwas mehr oder besser zu können, als zuvor mit der alten Lösung.

Mal schauen wie die Leute so reagieren, wenn die 4.5 LTS ausläuft und es keine Updates mehr gibt. Schätze mal, dass wird noch lustig für manche Agentur. 😉

Wie es unter der Motorhaube aussieht, ist nämlich den meisten Kunden eben VÖLLIG egal (solange der Motor läuft). Das ist ein Beispiel dafür, wie wenig aus dem Leben gegriffen, manche Argumente in dieser Diskussion sind.

Es spricht ja überhaupt nichts gegen neue (bessere) Technik. Nur den Kunden dazu zu zwingen und die möglichen Alternativen bewusst zu begraben, ist meiner Meinung nach eben nicht das richtige Signal. Damit wird nicht nur unzählig vielen Webdesignern (und Agenturen, etc.), sondern ebenso vielen Anwendern/Kunden die Freude an TYPO3 UNNÖTIG vermiest.

Das ist übrigens kein destruktives Kritisieren, sondern lediglich meine Meinung. Ich finde TYPO3 auch ohne TV gut, keine Frage. Nur ICH muss das ja auch nicht immer wieder neu machen lassen und bezahlen… 😉

Dennoch viel Spaß bei dem was Ihr so macht.
Es ist ja nur ein (großes) Stück Software…

Herzliche Grüße,
von Ralf

Ralf Becker am 03. Juni 2014 um 17:02

@Ralf Es gibt doch die 1.9.0, welche auch mit 6.2 kompatibel ist.
http://typo3.org/extensions/repository/view/templavoila

Philipp Gampe am 03. Juni 2014 um 19:13

@Phillip Danke, das wusste ich, dass da einige Leute dran weiter arbeiten. Darum ging es ja nicht… sondern um die vehemente Ablehnung (schon vor 6.x) gegenüber TV.
Ich hatte da lediglich auf einige der Kommentare reagiert…

Ralf Becker am 03. Juni 2014 um 19:31

@ralf
Du hast mir aus der Seele gesprochen.
Ich befinde mich nämlich gerade genau in der Situation, meinem für mich existenziell wichtigen Kunden zu erklären, warum er seine umfangreiche Website jetzt komplett neu aufsetzen lassen muss ohne für Ihn erkennbare Verbesserungen.
Es ist mir wirklich ein Rätsel, warum die Verantwortlichen den Schaden für Typo 3 nicht erkennen wollen, wenn so viele Anwender jetzt im Regen stehen.
Da rollen extreme (und für viele schwer nachvollziehbare) Kosten auf viele Anwender zu, die für Unmut sorgen werden und TV in keinem guten Licht erscheinen lassen.
Ich will damit nicht sagen, dass die Entwickler gezwungen sein sollten, TV ewig zu unterstützen – aber die Situation unzähliger Anwender und Dienstleister so garnicht zu verstehen und den Bedarf entsprechend einzuschätzen oder im Prinzip sogar zu unterstützen und Lösungen zu finden oder echte Alternativen zumindest anzudenken, sondern voll Freude einfach einen Cut zu unternehmen und das als Verbesserung zu feiern … ist für mich schwer zu verstehen.

Ralf am 04. Juni 2014 um 22:18

Wenn man jetzt nicht den Schlussstrich zieht, wird auch noch bei Version 10 Support für Uraltextensions wie TV verlangt, da man ja Legacyprojekte nicht einfach ohne Support lassen kann….. Wo sowas hinführen kann, sieht man beispielsweise bei der IE6-Unterstützung. Wieviele Mannjahre wurden wohl bis vor ein paar Jahre für sinnlose IE6-Kompatibilität aufgewendet, nur damit die damals modernen Seiten halbwegs auf Uraltbürorechnern aus dem Jahr 2004 liefen.
Abgesehen davon kommt das Ende von TV nicht unbedingt plötzlich. Das war bereits vor einem Jahr oder länger bekannt.

Boris Becker am 05. Juni 2014 um 01:41

Na, das mit dem IE-Problem zu vergleichen ist wohl völlig daneben. Der IE war total buggy und hat auf verschiedenen Ebenen nicht richtig funktioniert. TV hat schon immer funktioniert und ist nicht buggy in dem Sinne (nicht mehr, als andere Software auch).
Das TV JETZT nicht mehr funktioniert hat ganz andere Gründe.
Die Argumente der TV-Gegner zeigen mir immer wieder, dass sie oft weder praxisorientiert, noch technisch fundiert sind.

ICH bin froh, dass es Chrome, Firefox, Opera, IE und Safari (um nur mal die wichtigsten zu nennen) gibt und das NICHT irgendwelche Entwickler die Macht haben, einige davon als „UraltSoftware“ zu deklarieren und vom Markt zu schupsen. Der Anwender darf von Fall zu Fall selbst entscheiden, was er benutzen mag.

Ich verstehe nicht, was daran so schwer zu verstehen ist, dass VIELFALT immer schon ein Vorteil war und nicht das Gegenteil.
Musst doch niemand TV benutzen (tun nur Tausende sehr gerne!), wo ist das Problem?

Wenn ich vor der Umstellung einem Mediendesigner den Auftrag gab, ein Template mit (Div)Containern zu entwickeln und ihm eine Demo-Vorlage gab und ihm erklärte, wie das dann in TV gemapped wird, hatte es JEDER in 10 Minuten verstanden und legte los.

Wenn ich ihm heute als Vorlage ein Fluid-Template gebe, laufen die alle schreiend weg… 🙁

Naja… schauen wir mal was wird…

Ralf Becker am 05. Juni 2014 um 09:32

Typo 3 war bei den Designern eben genau deshalb sehr beliebt, weil wir einen Zugang hatten und es leicht und kostengünstig war, individuell gestaltete Seiten zu realisieren.
Es geht nicht um die Technik an sich oder dass es ein Unding ist, eine womöglich veraltete technische Lösung irgendwann einmal auszusortieren.
In diesem Fall ist nur erkennbar, dass eine der großen Vorteile von Typo3 – die große Akzeptanz bei den Designern – geradezu enthusiastisch über Bord geworfen wird wenn es keinen vergleichbaren Ersatz für die Möglichkeiten von TV gibt.
Gleichzeitig wird auf die tollen Möglichkeiten von Fluid verwiesen. Ich habe aber selbst bei wirklich neutralen Programmierern schon erlebt, dass sie die Gestaltung mit Fluid als kompliziert handhabbar empfunden haben und auf der Suche nach vergleichbaren Möglichkeiten von TV nur mit den Achseln gezuckt haben.
Es gibt doch einen Bedarf für ein CMS System mit dem designorientierte Seiten entwickelt werden können, das für Designer gut handhabbar ist und nicht für jede optische Modifikation immer gleich zwei aufwändige Ressourcen – Designer + Programmierer bindet, was das ganze zeitintensiv und teuer macht.
Das Argument IE wird hier meines Erachtens falsch interpretiert.
Dass sich landauf landab fast ALLE mit dem schrecklichen Problem abmühen mussten zeigt doch gerade, wo die Bedürfnisse des Marktes liegen. Es scheint viele Unternehmen zu geben, die der Meinung sind, dass Ihre Seiten auch auf 5 Jahre alten Systemen vernünftig laufen müssen.
Das ist die Realität, die ich als Dienstleister am Kunden vorfinde.
Natürlich mussten wir uns damit auseinandersetzen, obwohl wir es bescheuert fanden, weil wir es gewohnt sind, immer mit der neuesten Technik zu arbeiten und Lust auf Veränderungen hatten.
Wenn der Kunde dann nach der ersten Begeisterung die Rückmeldungen bekommt, dass „seine“ Seite bei seinem Freund XY oder in der Niederlassung „XY“ seines besten Kunden oder auf dem alten Laptop seiner Frau nicht richtig dargestellt wird, hatte man ein Problem…
Ich möchte nicht wissen, wie viele Designer, die glücklich waren mit Typo3, sich jetzt umschauen müssen, wie sie künftig ihre Projekte realisieren können, um dann mit viel Aufwand wordpress oder ähnliches zu verbiegen und Ihren Bedürfnissen anzupassen – nur weil sie es über Typo3 nicht mehr vermögen.
Ich kann mir nicht vorstellen, dass Typo3 wirklich gewinnt, wenn die Zugänglichkeit erschwert wird. Die Zahl der Installationen wird rapide abnehmen. Ich glaube nicht, dass die Entscheidungen bei Kunden für Typo 3 vornehmlich durch Entwickler und Programmierer getrieben war, sondern sehr stark auch durch die Agenturen und Designer, die eine Vorliebe für Typo3 entwickelt haben, weil sie ihre Gestaltung gut einbringen konnten und deshalb Typo3 ihren Kunden als Lösung vorgeschlagen haben.
Die IT-Leute und Programmierer waren schon früher tendenziell nicht unbedingt in der Mehrheit Typo3 Liebhaber und haben immer schon eher „gelästert“ über das Chaos der Open Source Lösung.
Aber vielleicht liegt darin auch die Sehnsucht der Entwickler.
Weg von der Open Source/Community Lösung hin zu mehr Akzeptanz bei den IT Verantwortlichen.

ralf am 05. Juni 2014 um 10:36

Meiner Meinung nach ist es genau umgedreht. Die meisten Designer wollen kein Typo3, da es viel schwieriger zu bedienen ist als beispielsweise WordPress. Zudem schaffen selbst Hobbydesigner das implementieren von WordPress HTML/PHP Mischmasch. Die die Typo3 wollen sind eher die Programmierer, die die zahlreichen Möglichkeiten von Typo3 oder Drupal gegenüber WordPress sehen.

fzkfzj am 05. Juni 2014 um 13:40

Also, ich will beides bitte. Ich will eine eierlegende Wollmilchsau, wo man alles bis ins kleinste verstellen und anpassen kann und das soll so schnell gehen, das man notfalls auch mal einen dressierten Affen dazu setzen kann. Wie die Extension dazu heißt ist mir wurscht, nur gehen muss es. Aber der Vergleich mit Microsoft kommt nicht von ungefähr. TYPO3 6.x ist wie Windows 8, am Kunden vorbei entwickelt, ausgestattet mit tollen Spielereien, die dann leider nicht so wirklich funktionieren(FAL,EM), bestehende Funktionen werden eingeschränkt(T3d Export, Scheduler) und die neue Installationsroutine soll einem wohl den Abschied erleichtern. Ich bin mir sicher das es für viele das letzte Update sein wird, sofern man es überhaupt macht. Ein Fork der 4.5 wäre sicherlich für einige interessant, zumindest bis man eine geeignete Alternative gefunden hat.

Freddy am 05. Juni 2014 um 16:44

Ja – ganz ehrlich … nachem ich nun eine mehrsprachige 6x Seite laufen habe und nach Monaten immer noch irritiert bin, dass ich einfach nicht den großen Fortschritt entdecken kann (obwohl ich wirklich nicht absprechen will, dass wahrscheinlich die Ressourcen, die ich nicht wirklich beurteilen kann und damit verbundene Möglichkeiten für die Zukunft wahrscheinlich wichtig sein können) – sondern im workarround mich eher zurückversetzt fühle, in die Jahre der ersten Begegnung mit Typo 3.
Ich will mich wirklich nicht gegen Änderungen wehren…
Aber die viel komplexere TV Seite, die ich betreue, fühlt sich geschmeidiger und flexibler an. Die Art und Weise wie ich dort referenzieren und verschieben kann in der Seitenpflege … Wie ich mal eben FCE’s generieren kann …
Es kommt einfach kein Gefühl auf, dass ich den Wunsch verspüre, die 4x auf die 6x upzudaten …
und die Gewissheit, jetzt viel Geld dafür auszugeben und einen Kunden unglücklich zu machen, ohne einen einzigen spürbaren Mehrwert für das Handling oder die Darstellung der Seite zu gewinnen, ist regelrecht deprimierend.
So etwas habe ich noch nie bei einem Software-Update empfunden. Und ich bin jemand der seit Jahrzehnten immer einer der ersten ist und normalerweise mit aktuellster Software arbeitet.
Sicher wurde viel Gutes gemacht … aber eben nicht hinsichtlich usability.

ralf am 05. Juni 2014 um 17:24

Ich bin ja froh, dass ich das nicht alleine so sehe. Nicht weil ich diesen Zuspruch brauchen würde, sondern weil ich an mich selbst das eine oder andere mal gezweifelt habe: „Bin ich zu altmodisch, zu konservativ, etc.?“.
Doch auch ich bin ein typischer Junge, der gerne mit neustem „Spielzeug“ spielt… WENN es denn Spaß macht, sprich wenn es funktioniert, was auf der Packung steht.
Wenn nicht habe auch ich die Tendenz, das Spielzeug in die Ecke zu pfeffern….

Nun wäre ich schon mal froh, wenn die 6.2 LTS so flexibel und leistungsfähig wäre, wie die 4.5 LTS. Ich bin gar nicht so vermessen, dass sie mehr können soll oder „besser“ sein sollte.

Ich finde, dass die 6.x (respektive 6.2 LTS) zu früh released wurde, weil eben nur ein Bruchteil der alten Feature zur Verfügung steht. Es ist vermessen oder arrogant, einfach für andere fest zu legen, was „man“ braucht und auf was „man“ verzichten kann.

Und all das hat nichts damit zu tun, dass ich nicht den Hut für die unglaublichen Leistungen der (Core)Entwickler ziehe und dessen Arbeit sehr wertschätze. Wirklich tolle Arbeit!
Nur ist etwas holprig der Schnitt zur vorhandenen TYPO3-Welt und den Wünschen vieler Integratoren, Designer und Anwender ausgefallen.

Ich fände es sehr schade, wenn TYPO3 mehr Anwender durch den harten Cut verliert, als es durch die moderne Technik unter der Haube von 6.2 gewinnen wird.

Ja, es ist etwa so, wie der schon genannte Windows 8 Vergleich.
Win8 kommt nicht wirklich an und funktioniert auch nicht so toll. Man braucht neue Rechner und alte Software läuft nicht mehr rund und man sieht auch nicht so wirklich den „Mehrwert“ usw….
Und XP wird nicht mehr unterstützt. Basta. Über die Argumente, dass WIN8 sicherer und moderner ist als das tooooootal veraltete XP, lachen sich sogar die Laien in Zeiten von Viren, Trojanern und der NSA halb Tod. 😉

Ich habe Kunden, die ernsthaft über Linux nachdenken… trotz aller Hürden.

Wenn TV mit ins Boot geholt worden wäre, hätte ich zig Kunden ein Update auf 6.2 vorgeschlagen und hätte ihnen gleichzeitig OPTIONAL ein Relaunch auf ein modernes Fluid-Responsive-Design (unter Bootstrap z. B.) angeboten.
Das Update hätte ich wie eh und je zu bezahlbaren und überschaubaren Kosten anbieten können und den Relaunch nach Aufwand.
Die Kunden hätten so eine ECHTE Wahl gehabt.

Die jetzige Situation gibt halt nur her, dass ich mal schön meinen Mund halte und erst mal noch nichts sage…

Wenn dann 4.5 LTS ausläuft, werde ich dass vielleicht so machen MÜSSEN wie Microsoft mit XP: „Beauftragen Sie ein Relaunch auf 6.2 mit neuer Design Entwicklung, oder sehen Sie zu, wie sie klar kommen. (Sicherheits) Updates Ihrer alten Website wird es nicht geben.“

Ich bin mal gespannt, wie viele Kunden Adieu sagen und wie viele so sehr an das Backend gewöhnt sind (oder Geld ausgeben wollen), dass sie das mit machen.

Ich nehme noch Wetten an. 😉

Ralf Becker am 05. Juni 2014 um 20:59

Seht Euch TYPO3 Mask an:
http://www.typo3experten.com/programmierung/mask.html

Wir entwickeln gerade einen würdigen TV-Nachfolger. Mit moderner Technik, frischen Ideen und intuitiv bedienbarem Erstellassistent.

Bis 10. Juli 2014 suchen wir noch Supporter:
http://www.startnext.de/mask
https://www.facebook.com/typo3mask
Wenn Euch Mask gefällt unterstützt uns, indem Ihr Fan auf Startnext und Facebook werdet, die Links weitergebt und das Crowdfunding gemeinsam mit uns zum Ziel bringt.

Vielen Dank – Gernot Ploiner

Gernot Ploiner am 14. Juni 2014 um 14:36

Nicht nur Templavoila gibt es inzwischen für Typo3 6.2 sondern auch Gridelements 3.0 (momentan nur in GIT aber bald auch in TER sobald die letzten 3 Bugs ausgemerzt sind)

Dies als Alternative insb. bei neuen Seiten 🙂

Andrew am 01. Juli 2014 um 14:55

Ich habe es geschafft, mit der Extension DCE (Dynamic Content Elements) und einem ViewHelper einen Inhaltsdatensatz einzubinden, der über ein Ordnersymbol ausgewählt werden kann. So können z. B. Container-Wrapper um Extensions gelegt werden o. ä. Mehr Informationen hier: http://www.julianstock.de/beitrag/2014-7-17-typo3-inhalte-tt-content-mit-viewhelper-in-extension-dce-rendern/

Julian am 17. Juli 2014 um 23:50

Hallo zusammen,

TL;DR:
TemplaVoila ist und bleibt ein wichtiger Abschnitt für TYPO3 auf dem Weg in die breite Öffentlichkeit.

Versnobbter Pseudo-Elitarismus hat noch keinem Projekt je weiter geholfen.

Click ’n Play statt Trial ’n Error – wir LIEBEN TemplaVoila!
🙂

Martin am 24. Juli 2014 um 19:02

Hallo Leute,

vielleicht dazu eine Anmerkung eines Users bzw. Redakteurs. Ich bin bin weder Programmierer, noch habe ich sonstwie Ahnung, was sich unter der Motorhaube von Typo3 so tut. Will ich auch gar nicht wissen! Ich pflege nur Inhalte ein. Punkt.

Das tue ich seit vielen Jahren auf mehreren Firmen-Websites und die waren alle mit Templa Voila. Macht Spaß und läuft bestens. Nun kam aus best. Gründen eine neue Website hinzu ohne TV. Ich kann nur sagen: furchtbar! TV ist um Längen intuitiver und bequemer zu bedienen. Ich stecke in die Pflege von nicht-TV-Seiten deutlich mehr Zeit (und Nerven) rein.

Das wollt ich nur mal sagen, um den TV-Anhängern den Rücken zu stärken. Das Ding mag für den Hardcore-Programmierer, der die reine Typo3-Lehre predigt, inakzeptabel sein aus technischen Gründen, aber für den User ist es ein echter Gewinn!

Bitte weiterentwickeln! Viele User danken es euch 🙂

Laie am 13. November 2014 um 11:49

Ich kann dem Redakteur in Seiner Analyse nur beipflichten, ich sehe jedoch einen anderen Weg zum Ziel. Fakt ist, dass dem Backend selbst in 6.2 ohne TV zum Teil noch essenzielle Funktionalitäten wie z.B. Kopieren/Ausschneiden/Einfügen-Buttons fehlen, Drag N drop ist nur halbherzig und hässlich implementiert, und auch die Arbeit mit mehrsprachigen inhalten kombiniert mit verschachtelten Elementen ist einfach nur grausam. Anstatt nun aber eine Krücke wie TV weiter zu benutzen sollte man lieber den Aufwand in die Verbesserung der Core-Funktionalitäten stecken um den Rekdatueren ein vernünftiges Arbeiten zu ermöglichen.

Moritz am 08. Mai 2015 um 17:45

Mask ist bereits seit 2015 im TER und ein guter Ersatz für alle die Templavoila mochten. Templavoila ist für TYPO3 7 oder höher nicht mehr kompatibel. Mit Mask hat man eine moderne Erweiterung, die auf Core Funktionalitäten setzt und als wesentlichen Bestandteil einen Wizard bereitstellt, um TYPO3 (tt_content oder pages) mit Feldern zu erweitern und eigene Contentelemente anzulegen.
Neu ist der Templavoila Konverter (http://tvconverter.webprofil.at/), mit dem man alte Templavoila-Projekte konvertieren und dann auf TYPO3 7.6 oder höher updaten kann. Ohne den Content neu eingeben zu müssen 🙂

Gernot Ploiner am 04. Juli 2016 um 20:07
Ein Kommentar hinterlassen


 Name


 Mail (wird nicht veröffentlicht)


 Website

Bitte beachten sie, dass ihr Kommentar möglicherweise erst freigeschaltet werden muss.

Kategorien

Archiv (Quick)

Juli 2016
M D M D F S S
« Jun    
 123
45678910
11121314151617
18192021222324
25262728293031