darum gehts nicht, sondern z.b. das linke menü in “site content”, warum muss ich da AJAX einsetzen um die seite zu wechseln? ein schöner netter link und gut ist, geht sogar schneller….

——————–
Wie schnell die Response vom Server ist, ist auch stark abhängig von Serverhardware und Softwaresetup. Wie gesagt da kann es 1000 Gründe geben. Übrigens: 40 MB Ram Unterschied sind heut zu Tage nicht mehr die Welt. Pro Tab sind sind 8 MB mehr - deshalb kriegt doch keiner einen Heulkrampf?
—————————

ich bin immer noch lokal……
doch wegen 40MB heule ich schon - weil das ganze eben nicht nur RAM braucht sondern wegen der menge auch zeit, wie gesagt seitenaufbauzeit LOKAL 3-4 sekunden und das ohne plugins (gut, das forum plugin ist drin, das braucht übrigens noch länger..) oder richtigen inhalt.

—————————
Nur mal so nebenbei: Ich hab schon mit ziemlich vielen CM-Systemen gearbeitet und war an der Entwicklung von mehreren System beteiligt. Da kannst Du mir eine objektive Sichtweise schon abnehmen: Das System ist sauber aufgebaut, aber wie erwähnt sicherlich noch an der einen oder anderen Stelle verbesserungswürdig.
—————————

mit sicherheit, sonst würde ich nicht wiederkommen. mein problem liegt einfach daran, das es hochgejubelt wird und keiner unter die fassade schaut und sich gefragt hat, warum das so langsam ist. das ist unnormal und sowas kannst du keinem normalen menschen anbieten, nicht einmal zum administrieren.

was an php dahinterliegt scheint - mit richtiger anleitung - logisch und verständlich zu sein. aber diess überladene admin konzept werde ich mir nicht antun….

Wie schnell die Response vom Server ist, ist auch stark abhängig von Serverhardware und Softwaresetup. Wie gesagt da kann es 1000 Gründe geben. Übrigens: 40 MB Ram Unterschied sind heut zu Tage nicht mehr die Welt. Pro Tab sind sind 8 MB mehr - deshalb kriegt doch keiner einen Heulkrampf?

Die meisten gewachsenen CM Systeme befinden sich ohnehin zur Zeit im Umbruch, was Entwicklung und Software-Strategie angeht. Um ein leistungsstarkes, schnelles und erweiterbares CMS aufzustellen ist viel Knowhow und vor allem Zeit notwendig. Und Silverstripe befindet sich da gerade erst am Anfang.

Nur mal so nebenbei: Ich hab schon mit ziemlich vielen CM-Systemen gearbeitet und war an der Entwicklung von mehreren System beteiligt. Da kannst Du mir eine objektive Sichtweise schon abnehmen: Das System ist sauber aufgebaut, aber wie erwähnt sicherlich noch an der einen oder anderen Stelle verbesserungswürdig.

Auf der anderen Seite zeigt es natürlich auch die Nachteile der Objektorientierung. Und, das man es eben noch besser machen kann. Der Autoload-Mechanismus ist sicherlich ein guter Ansatz.
————–

nein mit sicherheit kein schlechter ansatz, doch ist das eindeutig zuviel, das kann man nicht schön reden.

————-
Aber Sebastian, Du scheinst noch keinen Blick ins Typo3 Backend geworfen zu haben - da werden wesentlich mehr Files inkludiert, die oft nicht gebraucht werden. Bei anderen CM-Systemen siehts nicht besser aus.
————-

nö typo3 hab ich noch nie betrachtet. das es andere CM system auch so machen ist aber keine entschuldigung sondern ein armutszeugnis.

————-
Zu JS und CSS Files - die werden ohnehin vom Browser gecacht. Statische Files die nachgeladen werden, machen weder beim Browser noch beim Webserver performance-technisch den Bock fett…
————-

ach in der administration für den webserver eh nicht. es geht aber darum, das 1 MB JS + CSS eben RAM frisst und den browser erheblich verlangsamen kann. zu sehen ist das eindeutig dadurch, das die administration LOKAL 3-4 sekunden zum laden braucht. 5 silverstripe tabs und der FF3 braucht 100 MB ram im gegensatz zu 5 heise tabs die 60MB brauchen. schön finde ich auch die komische AJAX implementierung z.b. in der seitenübersicht wo das laden des einzelnen teilstücks länger braucht als wenn mans “richtig” neu geladen hätte. oder “files & images” wo immer das silverstripe logo zu sehen ist - weil der AJAX content solange zum laden braucht. wenn das das web 2.0 ist, will ich das web 0.5 zurück….

Auf der anderen Seite zeigt es natürlich auch die Nachteile der Objektorientierung. Und, das man es eben noch besser machen kann. Der Autoload-Mechanismus ist sicherlich ein guter Ansatz.

Aber Sebastian, Du scheinst noch keinen Blick ins Typo3 Backend geworfen zu haben - da werden wesentlich mehr Files inkludiert, die oft nicht gebraucht werden. Bei anderen CM-Systemen siehts nicht besser aus.

Zu JS und CSS Files - die werden ohnehin vom Browser gecacht. Statische Files die nachgeladen werden, machen weder beim Browser noch beim Webserver performance-technisch den Bock fett…

Wie auch immer, trotzdem ein bemerkenswerter Ansatz für ein CMS.

gut weiter, das backend includiert zwar wenig JS aber dafür 95 PHP dateien auf der hauptseite. die administration includiert nocheinmal 136 PHP dateien. ich weiß nicht wer das programmiert hat, aber es erinnert mich doch fatal an die szene aus Apollo 13 wo “ein eckiges schwein in ein rundes loch” passen musste (der co2 filter).

Wie gesagt, insgesamt eine sehr gelungene Ausgabe!