Es wird auch jeder bestätigen dass das Teil im Punkt Usability eher schlechtes Untermaß ist. Die Idee ist gut, die Umsetzung lässt sich mit Gewöhnung vermutlich auch gut benutzen aber für jeden Einsteiger eine einzige Katastrophe.
es gibt halt user und entwickler. entwickler entwickeln halt und user nutzen und meckern. bist ja nicht gezwungen, open source zu nutzen. am besten kennt sich halt immer der aus, der daran arbeitet. wenn ich meine sourcen betrachte, ist es für manche auch chaotisch. für mich ist es aber o.k., da ich meinen code gut nutzen kann. so wird es bei den typo-codern auch sein.
mach' doch mit, mach's besser und investiere deine energie sinnvoller.
"entwickler entwickeln halt und user nutzen und meckern."
Wenn ich nur rants höre über den Quellcode, will ich ehrlich gesagt das Produkt lieber nicht nutzen.
Aber ist PHP oder? Dann überrascht micht nichts.
Es wird die Zeit kommen wo auch auf dem WWW eine Sprache kommt, die in allen praktischen Bereichen besser ist als php UND die gute WWW-Applikationen auf die Beine stellt.
Typo3 ist umständlich, holprig und langsam. Ein wahres Monstrum. Fürchterlich.
Quanta + in Verbindung mit anderen - z.B. kfilereplace - ist da wesentlich schneller, eleganter - und Quanta + produziert auch einen Code, der sauber ist. Der Code von Typo3 ist ein absoluter Graus und eine Zumutung.
Ich habe mir vor kurzem mal die Mühe gemacht und gemessen, um einem Kunden klar zu machen in welchen "Dimensionen" der Langsamkeit TYPO3 sich bewegt! Zum Teil brauchte TYPO3 mehr als 500ms um eine Seite zu generieren, während die gleiche Seite mit einem optimierten C++-CGI-Programm (C++-Framework, CMS-System) in weniger als 0,2ms generiert wurde. Die Test-Maschine war ein Root-Server bei STRATO (Opteron, 4GB RAM).
Das Typo3-Rendering ist komplex und sehr flexibel, sieht man schon an Dingen wie TemplaVoila und RealURL. Sind die Seiten einmal generiert so kommen sie aus dem Cache, das ist wesentlich schneller als das Neugenerieren. Wem das zu langsam ist kann sich auch noch statische HTML-Seiten on-the-fly generieren lassen, dann liefert Apache solange reine HTML-Seiten aus, bis sie ungültig sind und ersetzt werden.
Welches andere CMS kann das!? Zudem kann ich ein Typo3 auch noch Clustern.
Kleiner Benchmark: Meine Typo3-Seiten werden innerhalb von 200ms gerendert UND zum Client ausgeliefert, danach verringert sich die Zeit auf 100-150ms (Cache-Hit).
wir arbeiten meistens mit http://de.wikipedia.org/wiki/Tntnet und eigens entwickelten "c++-html-producer-klassen", die wir für kunden jeweils speziell anpassen. weiterhin haben wir auch einen eigenen webserver mit einem internen und sehr schnellen cache entwickelt, den wir zusammen mit den html-klassen direkt kompilieren. dabei entstehen meistens maßgeschneiderte cms-systeme. die performance ist einfach unschlagbar. und im endeffekt sind wir dabei meistens kaum teurer als typo3-agenturen.
"Der Code von Typo3 ist ein absoluter Graus und eine Zumutung.
Ja, der Code, den Typo3 produziert, ist aber nicht nur technisch gesehen schlecht. Er "frisst" auch im Vergleich zu schlankem und sauberem Code extrem Strom. Das sind Dimensionen, die wir im Moment noch kaum richtig beurteilen können. Ich vermute, dass ein oder mehrere AKW's in Deutschland nur für unnötig aufgeblähten und teilweise fehlerhaften Code laufen. Es wird Code produziert, bei dem der echte Content im Verhältnis zum Rest 1 % ausmacht. Das ist, wie wenn ein einziger Mensch mit einem Zug samt etlichen Anhängern jeden Tag zur Arbeit fährt.
Auch hier muss ein Umdenken stattfinden. Wie auch bei den Autos. Das Problem ist u.a., dass viele den Bildschirm mit dem Fernseher verwechseln: alles muss schön bunt und animiert sein - die Information ist nicht wichtig. Das zielt alles in Richtung "Infantilisierung der Gesellschaft". Sorry, bin gerade vom Thema abgekommen. Wollte nur sagen: Produziert sauberen Code für intelligente Menschen ...
Arbeitet Typo jetzt auch mit modernem XHTML? Schon lange.
Die Seiten von Typo selbst sind jedenfalls nicht mal valides HTML40 Transitional. Warum eigentlich? Weil das Template HTML 4.0 vorgibt, TYPO3 aber XHTML generiert. Der Validator moniert den Slash am Ende der leeren Elemente. Würde sich endlich mal jemand mit nem XHTML-konformen Template beschäftigen, wäre die Seite valides XHTML.
> Der Validator moniert den Slash am Ende der leeren Elemente
Scheint tatsächlich auf die meisten Fehler zuzutreffen - schon mal ein gutes Zeichen, das sollte leicht zu fixen sein.... Es gibt allerdings auch ausgesprochen krude echte Fehler wie etwa ein H3, das in(!) einem A steht.
Gibt es denn für Typo auch fertige XHTML-konforme Templates?
Ist allerdings nicht GPL - CC attribution sharealike, wenn ich das richtig verstehe. Hmmmm... Der Link auf die Lizenz zeigt jedenfalls auf: http://creativecommons.org/licenses/by/2.0/de/
Die Bedingungen auf der Seite des Autors: http://yaml.t3net.de/Nutzungsbedingungen.67.0.html
gehen aber über attribution hinaus. Was ist es nun: sharealike attribution(das wäre OK) oder sharealike attribution non-commercial?
Letzteres würde vor allem die Frage aufwerfen, wie mit Derivaten/Forks zu verfahren wäre...
Die Lizenz ist CC-A. Du musst also im Footer jeder Seite auf das Projekt hinweisen. Das mit der kommerziellen Lizenz ist wie bei Qt. Auch dort heißt es, wer das Toolkit kommerziell einsetzen will, soll blechen, wobei hier kommerziell mit "ich will meinen Quellcode nicht preisgeben" gleichgesetzt wird. Und bei YAML ist es halt der Verzicht auf die Nennung des eigentlichen Autors des Templates.
Es gibt allerdings auch ausgesprochen krude echte Fehler wie etwa ein H3, das in(!) einem A steht. Das scheint ein Fehler bei der Verwendung der TypoScript-Funktion stdWrap zu sein. Man wollte es sich bei der Link-Formatierung wohl zu einfach machen.
bist ja nicht gezwungen, open source zu nutzen.
am besten kennt sich halt immer der aus, der daran arbeitet. wenn ich meine sourcen betrachte, ist es für manche auch chaotisch. für mich ist es aber o.k., da ich meinen code gut nutzen kann. so wird es bei den typo-codern auch sein.
mach' doch mit, mach's besser und investiere deine energie sinnvoller.
Wenn ich nur rants höre über den Quellcode, will ich ehrlich gesagt das Produkt lieber nicht nutzen.
Aber ist PHP oder? Dann überrascht micht nichts.
Es wird die Zeit kommen wo auch auf dem WWW eine Sprache kommt, die in allen praktischen
Bereichen besser ist als php UND die gute WWW-Applikationen auf die Beine stellt.
Und was hat das bitte mit PHP zu tun? Hässlichen Code kann man in jeder Sprache schreiben.
Quanta + in Verbindung mit anderen - z.B. kfilereplace - ist da wesentlich schneller, eleganter - und Quanta + produziert auch einen Code, der sauber ist. Der Code von Typo3 ist ein absoluter Graus und eine Zumutung.
Ich habe mir vor kurzem mal die Mühe gemacht und gemessen, um einem Kunden klar zu machen in welchen "Dimensionen" der Langsamkeit TYPO3 sich bewegt! Zum Teil brauchte TYPO3 mehr als 500ms um eine Seite zu generieren, während die gleiche Seite mit einem optimierten C++-CGI-Programm (C++-Framework, CMS-System) in weniger als 0,2ms generiert wurde. Die Test-Maschine war ein Root-Server bei STRATO (Opteron, 4GB RAM).
Wem das zu langsam ist kann sich auch noch statische HTML-Seiten on-the-fly generieren lassen, dann liefert Apache solange reine HTML-Seiten aus, bis sie ungültig sind und ersetzt werden.
Welches andere CMS kann das!? Zudem kann ich ein Typo3 auch noch Clustern.
Meine Typo3-Seiten werden innerhalb von 200ms gerendert UND zum Client ausgeliefert, danach verringert sich die Zeit auf 100-150ms (Cache-Hit).
System: AMD Athlon 64 (SingleCore), 2GB RAM, Apache 2.2, PHP 5.2, MySQL 5.0
Ja, der Code, den Typo3 produziert, ist aber nicht nur technisch gesehen schlecht. Er "frisst" auch im Vergleich zu schlankem und sauberem Code extrem Strom. Das sind Dimensionen, die wir im Moment noch kaum richtig beurteilen können. Ich vermute, dass ein oder mehrere AKW's in Deutschland nur für unnötig aufgeblähten und teilweise fehlerhaften Code laufen. Es wird Code produziert, bei dem der echte Content im Verhältnis zum Rest 1 % ausmacht. Das ist, wie wenn ein einziger Mensch mit einem Zug samt etlichen Anhängern jeden Tag zur Arbeit fährt.
Auch hier muss ein Umdenken stattfinden. Wie auch bei den Autos. Das Problem ist u.a., dass viele den Bildschirm mit dem Fernseher verwechseln: alles muss schön bunt und animiert sein - die Information ist nicht wichtig. Das zielt alles in Richtung "Infantilisierung der Gesellschaft". Sorry, bin gerade vom Thema abgekommen. Wollte nur sagen: Produziert sauberen Code für intelligente Menschen ...
Schon lange.
Die Seiten von Typo selbst sind jedenfalls nicht mal valides HTML40 Transitional. Warum eigentlich?
Weil das Template HTML 4.0 vorgibt, TYPO3 aber XHTML generiert. Der Validator moniert den Slash am Ende der leeren Elemente. Würde sich endlich mal jemand mit nem XHTML-konformen Template beschäftigen, wäre die Seite valides XHTML.
Scheint tatsächlich auf die meisten Fehler zuzutreffen - schon mal ein gutes Zeichen, das sollte leicht zu fixen sein.... Es gibt allerdings auch ausgesprochen krude echte Fehler wie etwa ein H3, das in(!) einem A steht.
Gibt es denn für Typo auch fertige XHTML-konforme Templates?
a? Was ist a? Hoffentlich kommen bald XHTML2... ;)
lg
Erik
Ja, z.B. YAML für TYPO3
cool Danke :-)
Ist allerdings nicht GPL - CC attribution sharealike, wenn ich das richtig verstehe. Hmmmm...
Der Link auf die Lizenz zeigt jedenfalls auf:
http://creativecommons.org/licenses/by/2.0/de/
Die Bedingungen auf der Seite des Autors:
http://yaml.t3net.de/Nutzungsbedingungen.67.0.html
gehen aber über attribution hinaus. Was ist es nun: sharealike attribution(das wäre OK) oder sharealike attribution non-commercial?
Letzteres würde vor allem die Frage aufwerfen, wie mit Derivaten/Forks zu verfahren wäre...
Das mit der kommerziellen Lizenz ist wie bei Qt. Auch dort heißt es, wer das Toolkit kommerziell einsetzen will, soll blechen, wobei hier kommerziell mit "ich will meinen Quellcode nicht preisgeben" gleichgesetzt wird.
Und bei YAML ist es halt der Verzicht auf die Nennung des eigentlichen Autors des Templates.
Das scheint ein Fehler bei der Verwendung der TypoScript-Funktion stdWrap zu sein. Man wollte es sich bei der Link-Formatierung wohl zu einfach machen.