Hallo Joey, Am 11.05.2010 15:15, schrieb JoH asenau:
> Es geht dabei weniger um die Performance beim Ausliefern der Seiten im > Frontend allein sondern um die Art und Weise, wie die Daten in der Datenbank > abgespeichert werden. Der gesamte Inhalt einer Seite wird über ein großes > XML Konstrukt in ein einziges Datenbank-Feld geschrieben, was sich sowohl im > Frontend als auch im Backend entsprechend auswirkt. Wenn hier von > Performance die Rede ist, dann nicht nur von Millisekunden im FE sondern > z.B. auch von Arbeitsstunden für Redakteure oder Entwickler. Ja, bei Benutzung von FCEs > Standard-Mechanismen auf Datenbank-Ebene wie z.B. colPos, sorting etc. > werden komplett ausgehebelt. Das CONTENT Objekt wird damit mehr oder weniger > unbenutzbar, weswegen TV per Default auch ausschließlich mit RECORDS > arbeitet. Zusätzliche Abfrage-Möglichkeiten, die bei CONTENT z.B. über where > oder andWhere hinzugefügt werden können, um die Ergebnismenge einzuschränken > sind dort nicht möglich. Ja, bei Benutzung von FCEs > Selbst wenn man die pid eines Datensatzes kennt, > muß man dennoch die XML Struktur befragen, weil er ja auch zu den "unused > elements" gehören könnte. Ja, das ist eines der ärgerlichsten Punkte überhaupt. > Eine Abfrage auf Datenbank-Ebene wird dadurch erheblich erschwert, wenn > nicht unmöglich gemacht, da die XML Struktur eines jeden Datensatzes > einzeln(!) komplett aufgedröselt werden muß, um die einfachsten Dinge > herauszufinden. Was das für den Speicherbedarf und die Geschwindigkeit > solcher Abfragen bedeutet, dürfte klar sein. Auch hinsichtlich einer > Anbindung der Daten an andere Systeme ist TV was die interne Datenhaltung > angeht eine mittlere Katastrophe. Ja, bei Benutzung von FCEs > Wobei man anerkennen muß: Es erfüllt seinen Zweck was die > Benutzerfreundlichkeit angeht und die Performance-Einbußen halten sich in > Grenzen, je kleiner die Site und damit der Umfang der Datenbank ist. > Deswegen sind es in unserem Kundenkreis vor allem größere Ex-TV-Projekte mit > einer Anzahl an Seiten jenseits der 5-Stellen-Grenze, die Zug um Zug von TV > auf Standard-Templating "rückgebaut" werden - und zwar nicht etwa, weil wir > darauf drängen würden, sondern weil die Verantwortlichen selbst begriffen > haben, daß das "futuristic template building" nicht ganz so future proof > ist, wie man angenommen hatte. Die Kritik kann ich teilweise sehr gut nachvollziehen. Das Hauptproblem ist dabei m. E. aber nicht Templavoila als ganzes, sondern eher die "Flexible Content Elements" (FCE). Diese sollten wirklich nur für minimalistische Dinge eingesetzt werden und können bei komplexeren Problemen eine ordentlich programmierte Extension keinesfalls ersetzen. Wie von Dir erwähnt, bringt TV hinsichtlich der Benutzerfreundlichkeit einige Vorteile. Wenn ich es richtig verfolgt habe, dann wird man mit TYPO3 4.4 im Backend aber auch mehr gestalterische Anpassungen bei den Spalten vornehmen können (oder war es eine neue Extension...?), so dass dieser Vorteil von TV auch weg fällt. Bleibt noch der Vorteil von TV mittels FCE eine Inhaltsspalte weiter zu unterteilen. Ich glaube, Deine ICE-Pack-Extension kann so etwas ähnliches auch, oder? Ich hatte mir diese zwar mal vor längerer Zeit angesehen, bin damals aber nicht so richtig mit warm geworden. Viele Grüße Marco _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
