nicht angemeldet
...allen Übels ;)
Ich habe gerade Mathias' Weblog Eintrag durchgelesen, in dem unter anderem einige Probleme mit JavaScript-Bibliotheken angesprochen werden.
Dein Artikel stellt ja (unter anderem) eine Anleitung dafür dar, wie eine solche erstellt wird, daher dachte ich, dass meine Anmerkung hier eventuell besser als im Weblog-Kommentar aufgehoben sind, da ich gerne explizit auf deine Arbeit Bezug nehmen möchte. Eine Vielzahl dieser 'Framworks' sind in meinen Augen 'over-engineered'. Dein Framework zeigt hier im Kleinen, was in meinen Augen im Großen schief läuft (was jetzt keinesfalls abwertend dir gegenüber klingen soll: ich habe großen Respekt vor der Arbeit, die du offensichtlich in deinen Artikel gesteckt hast; meine Kritik ist vielmehr konzeptioneller Natur).
Ich hatte damals deinen ursprünglichen Thread verfolgt, in dem peterS. ja auch einen alternativen Lösungsansatz vorgestellt hatte. Das hatte mich dazu animiert, eine eigene objektorientierte Lösung zu entwickeln, die ich jetzt als Gegenentwurf zum Framework-Konzept präsentieren möchte.
Das Framework leistet ja vor allem eins: Es stellt eine Fabrik-Methode mit variabler Zahl benannter Parameter zur Erzeugung von Fader-Objekten bereit und kümmert sich um die Interna der Verwaltung mehrerer Fader.
Mein Konzept verzichtet auf ein umschließendes Framework: der Nutzer hantiert direkt mit den Fader-Objekten.
Das funktioniert wie folgt: Anstelle einer Fabrik-Methode wird direkt der Konstruktor aufgerufen. Als Argumente werden nur die tatsächlich benötigten und für jeden Fader verschiedenen Parameter angenommen, bei meinem Fader also die id des Bildelements und ein Array mit den Adressen der weiteren Bilder. Möchte man von den Standardwerten abweichende Werte für die anderen Parameter (z.B. loop, clickable, random, ...), werden diese direkt dem Objekt hinzugefügt (die Standardwerte liegen im Prototyp).
Alles weitere passiert asynchrom im Hintergrund (vorladen der Bilder im Konstruktor, Modifikation des DOM beim ersten 'Schritt' des Faders). Der Nutzer ruft einfach nach initialisieren des Faders dessen start-Methode auf, und das Objekt selbst kümmert sich darum, dass das Bild in ein inline-block-Element gekapselt wird und der Bildwechsel beginnt, sobald alle Bilder geladen sind - es besteht hier keine Notwendigkeit für die weitere Abstraktionsebene 'Framework'!.
Zur Veranschaulichung des Konzepts ein Auszug aus meiner Beispieldatei:
var images = ['1.gif', '2.gif', '3.gif', '4.gif'];
var fader = new Fader('fader', images);
with(fader) {
loop = true;
random = true;
stepTime = 50;
stepCount = 10;
}
fader.start();
Der Code steht in einem script-Block im <head/>. Die start-Methode kann aber grundsätzlich jederzeit (nach Objekt-Initiolisierung) aufgerufen (oder sogar einem Element als Event-Handler zugewiesen) werden.
Christoph
Gunnar Bittersmann
Struppi