[TYPO3-german] RedDot vs. Typo3 ?

[André Esch]

Hallo Elmar,

ich gebe Dir und Herrn Kindström absolut recht. Ich denke
auch dass viele Probleme bei TYPO3 aus den Extensions
herrühren und das viel wert darauf gelegt werden sollte, diese
in den stable-Status zu führen.

Ich würde mich selbst noch als absoluter Anfänger bezeichnen
was T3 angeht, obwohl ich Aufgrund des großen Pojektes und meiner
Erfahrungen mit anderen CMS-Systemen schon teilweise verdammt
tief in den Kern vorgestoßen bin. Einer der großen Unterschiede
zwischen RD und T3 für mich ist, dass man bei RD nicht so tief
in den Kern vorstoßen muss aber auch nicht kann. Und genau
da liegt auch der Vorteil und der Nachteil beider Systeme. T3 läßt
sich wesentlich besser steuern. Man kann und muss teilweise viel
mehr ins Detail gehen. Dafür stehen einem halt auch nahezu alle
Türen offen, während bei RD viele Türen verschlossen sind. Einige
sind gar nicht zu öffnen und andere nur mit sehr viel Geld.

Deswegen sagte ich ja, dass wir bei jedem Projekt eine Bedarfsanalyse
machen und danach entscheiden welches CMS eingesetzt wird. Jetzt
werden viele sagen "das ist völlig normal das man das macht." Ich
denke die Realität sieht etwas anders aus. Für gewöhnlich hat man
sein favorisiertes CMS und versuchen den Bedarf damit abzudecken
aber das geht jetzt zu weit.

Von einem Abflachen der Lernkurve bin ich jedenfalls noch verdammt
weit weg ;-( In meinen Augen haben übrigens die viele wirklich
mächtigen CMS-System eine sehr steile Lernkurve.

Viele Grüße aus Köln
der André


"Elmar Hinz" <elmar.DOT.hinz at team.MINUS.red.DOT.net> schrieb im Newsbeitrag 
news:mailman.1.1138741218.17163.typo3-german at lists.netfielders.de...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> Ein weiterer Vorteil ist dass Reddot echte, pure HTML-Seiten produziert
>> und damit wesentlich weniger Hardwareaufwand bei Hightraffic Sites
>> fordert.
>
> Ich bin nicht gerade der Techniker. Aber ich denke, wenn man einen Squid 
> davor
> hängt. müßte man bei dynamisch erzeugten Seiten mindestens zu 
> vergleichbaren
> Ergeninssen kommen als bei Seiten, die statisch von einem Webserver 
> ausgeliefert
> werden.
>
> Ich würde vermuten, daß ein Squid mindestens eine so gut Performance 
> zeigt, wie
> ein Server, der HTML pur von der Festplatte ausliefert. Da sicher zu 70% 
> immer
> dieselben 10 Webseiten ausgeliefert werden, dürfte ein Squid mindestens 
> 95% der
> Anfragen permanent im Arbeitsspeicher vorhalten können und damit 
> vergleichbar
> günstigere Werte erreichen. Immerhin wurde der Squid ursprünglich 
> entwickelt um
> statische Seiten zu beschleunigen. Ihm ist es egal, ob die Quelle statisch 
> oder
> dynamisch ist.
>
> Gerade bei gigantischen Seitenzahlen dürften die zusätzlichen 
> Einrichtungs- und
> Adminkosten dafür auch kaum noch ins Gewicht fallen.
>
>> Nachteile:
>> Mördermäß schwieriger Einstieg
>> Schlechte Dokumentation (vor allem wenn es in die Tiefe geht)
>
> Wenn Du in der Tiefe angekommen bist, hast Du aber Sourcecode, der sich 
> "selbst
> dokumentiert". Diese Quelle ist für den kleinen Kunden zu teuer zu 
> erschließen.
> Aber gerade bei großen, langfristigen Projekten, kann man das kaum genug
> unterstreichen. Sicherlich ein Verkaufsargument, was immer noch nicht 
> genügend
> in den Vordergrund gerückt wird. Welche vergleichbaren Systeme können das 
> von
> sich behaupten?
>
> Die extrem steile Lernkurve kann ich aus eigener Erfahrung absolut 
> bestätigen.
> Jedenfalls, wenn man tiefer vordringen will als der reguläre Editor. Erst
> nachdem ich ein Buch drüber gschrieben hatte, hatte ich das Gefühl das 
> System
> grundsätzlich in den meisten Winkeln zu verstehen. Das kann und darf aber 
> nicht
> die Standardsituation sein.
>
> Für die Autoren der verschienen TYPO3 Bücher ist die Frage darum extrem
> spannend, diese Lernkurve abzuflachen und damit ihre Teil zum Erfolg von 
> TYPO3
> bezutragen. Das teuerste Buch ist immer noch extrem viel preiswerter als 
> die
> kleinste RedDot Schulung und ein einziger guter Hinweis kann durch die 
> gesparte
> Zeit schon den Anschaffungspreis refinanziern. Darum lohnt es sich hier
> unbedingt ein paar Gedanken zu investieren, wie man diese Lernkurve von 
> TYPO3
> abflachen kann. Ich bin für diesbezügliche Anregungen sehr dankbar.
>
> Dennoch glaube ich, daß der größere Teil der Probleme mit TYPO3 aus 
> Extensions
> resultiert, die nicht mit anderen Extensions kooperieren, die fehlerhaft 
> sind,
> die erst eine sehr aufwendige Konfiguration benötigen und die schlecht 
> oder gar
> nicht dokumentiert sind.
>
> Ich denke genau hier sollte die TYPO3 Kommunity viel mehr Aufmerksamkeit
> investieren. Um diese Probleme anzugehen, haben wir im Dez. das Extension
> Coordination Team (ECT) gegründet. Das Tolle daran ist, daß wir nicht die
> Ressourcen des Core Teams abziehen müssen, sonder aus dem Pool der 
> Extension
> Entwickler neue Ressourcen für ein gut funktionerendes System erschließen 
> können.
>
> Peter Kindström hat das in t.dev sehr gut auf den Punkt gebracht:
>
> I think you all have to be patient!!! The ECT is newly born and it is not 
> very
> easy to change the community away from the "do it yourself" mentality to a
> "cooperation" mentality!
>
> Ich hoffe Ihr unterstützt alle diesen Mentalitätswandel, damit das 
> Extension
> Chaos irgendwann ein Ende hat.
>
> Elmar
>
> - --
> Climate change 2006 is killing people: floods in California, drought and 
> fires
> in Australia, Texas, Sahel, Oklahoma, South Africa. The Bush 
> administration is
> responsible for corruption of the Kyoto Protocol. The US majority is 
> responsible
> to the world for reelection of a convictable [...censored by Echelon...].
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFD38/eO976RNoy/18RAtmpAJ0Wo70cyE1ot/5bj7/q9rd4Y9FDWACfWVwS
> oXYBfDHqjeDZ2CeNGfLWp/Q=
> =j3rZ
> -----END PGP SIGNATURE-----