molily: Was läuft schief im JavaScript-Land: Frameworks, die Wurzel...

Beitrag lesen

Hallo,

es besteht hier keine Notwendigkeit für die weitere Abstraktionsebene 'Framework'!.

Wenn ich davon ausgehe, dass nicht alle Bilder der Slideshow, sondern nur eines von Anfang an im HTML-Code liegen, kann ich das Vorladen natürlich dem Script überlassen. Ich persönlich finde beide Ansätze nicht so vorteilhaft, für mich hat eine solche Slideshow »unobtrusive« zu sein, bei der alle Bilder schon im Dokument liegen. Wobei eigentlich nicht alle Bilder geladen sein müssen, damit die Slideshow starten kann. Wenn ich das richtig sehe, dann werden in Felix Script die Bilder zwar vorgeladen, es wird aber nicht auf den Erfolg gewartet.

Wenn ich nicht siebenunddreißig Objekte einzeln pollen lassen will, ob das DOM schon verfügbar ist, besteht durchaus die Notwendigkeit, diese Funktionalität zu zentralisieren. Und da bin ich glücklich, dass Felix’ Artikel das Setzen mehrerer load-Handler beschreibt. Gut, man hätte auch das mit deinem Konzept der autonomen Fader-Objekte mit geteilten privaten Methoden lösen können. Andererseits könnte man das Objekt FaderFramework ebenfalls in eine Funktion auflösen. Ich denke, diese beiden Umsetzungen geben sich wenig. Didaktisch gesehen halte ich die Abstraktionsebene eher für verständnisfördernd.

Was an deiner Struktur anders ist, ist natürlich eine Sache, die Felix derzeit ausklammert und die einer eigenen Betrachtung bedarf: Private Methoden, in einer Funktion über dem Konstruktor, sodass sie nicht mit jeder Instanz neu angelegt werden, aber eine Kontextkorrektur nötig haben.

Mathias