Wenn die Fader-Funktionalität auf mehreren Seiten einer Webpräsenz eingesetzt werden soll, dann ist es sehr umständlich, den JavaScript-Code dafür immer im Kopf einer jeden Datei zu notieren. Auch Änderungen an der Funktionalität lassen sich so nur sehr schwer pflegen. Daher ist es sinnvoll, diese Funktionalität in eine externe Datei auszulagern, die dann bei Bedarf ins Dokument 
nachgeladen wird.
Eine solche Vorgehensweise entspräche auch dem Ideal von "unobtrusive JavaScript" (bedeutet in etwa "unaufdringliches" oder "unauffälliges" JavaScript), indem man den JavaScript-Code gänzlich aus dem HTML-Dokument verbannt. Auch wenn das in der Praxis vielleicht nie überall gelingen wird, so lohnt es sich doch in dem Moment, in dem immer wieder benötigte Funktionalitäten zentral bereitgestellt werden. Außerdem gelingt es so viel leichter, JavaScript-Funktionalität als eine zusätzliche "Verhaltens"-Schicht einer Webseite von der reinen Inhaltsschicht und der rein visuellen Präsentationsschicht zu trennen. Der Nachvollziehbarkeit der Beispiele in diesem Artikel wegen wird das aber erst gegen Ende tatsächlich so gehandhabt werden.
Für dieses Projekt wäre es daher ganz praktisch, wenn man eine Rahmenapplikation hätte, die das Handhaben und die Erzeugung der Fader übernehmen, und deren Code außerdem aus einer externen Datei nachladen könnte. Auf diese Weise bräuchte sie vom Browser nur einmal geladen werden, auch wenn sie auf mehreren Unterseiten Verwendung findet. Diese Rahmenapplikation könnte sich dann beim Laden der Seite selbst initialisieren, um sowohl die Fader einzurichten (und vielleicht sogar automatisch zu starten), als auch den benötigten CSS-Code automatisch ins Dokument zu integrieren.
Um alle diese Forderungen zu erfüllen, sind Mechanismen erforderlich, die nun im Einzelnen behandelt werden, bevor sie in einem größeren Rahmen-Objekt (Framework) zusammengefasst werden.
Eine CSS-Datei nachzuladen bedeutet, ein <link>-Element dynamisch zu erstellen, ihm die notwendigen Attribut-Werte zuzuweisen, und es in den <head>-Bereich des Dokuments einzuhängen. Der Browser lädt dann diese Datei nach und aktualisiert die Darstellung des Dokuments.
Die Erzeugung eines neuen HTML-Elements geschieht mit der document-Methode createElement(), der als Parameter der Name des Elements (in diesem Fall "link") übergeben wird. Mit der Methode appendChild() kann das so erzeugte Element einem anderen Element als Kindelement am Ende angefügt werden.
Anzeigebeispiel: So sieht's aus
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>Ladebalken</title>
<script type="text/javascript">
function cssNachladen() {
var e = document.createElement("link");
e.type = "text/css";
e.rel = "stylesheet";
e.href = "beispiel.css";
document.getElementsByTagName("head")[0].appendChild(e);
}
</script>
</head><body>
<h1>CSS-Datei nachladen</h1>
<p>Klicken sie auf den Link, um eine CSS-Datei dynamisch nachzuladen!</p>
<p><a href="javascript:cssNachladen()">nachladen</a></p>
</body></html>
Die Funktion cssNachladen, die durch einen Klick auf den Link aufgerufen wird, erzeugt ein <link>-Elementobjekt und speichert es in der Variablen e. Anschließend werden dem link-Objekt die für ein <link>-Element wichtigen Attribute wie type, rel und href als Objekt-Eigenschaften verliehen. Schlussendlich wird das Element über appendChild an das Ende des <head>-Elements angehängt.
Die Reihenfolge, in der Stylesheets im <head> einer Datei referenziert werden, kann Auswirkungen auf die Darstellung haben! CSS-Regeln einer vorher referenzierten Datei können nämlich durch anderslautende Regeln einer danach referenzierten Datei überschrieben werden.
Im Standardumfang von JavaScript existiert zwar ein Objekt document.body, jedoch kein Objekt document.head, weshalb hier der Umweg über document.getElementsByTagName("head")[0] genommen wurde, um das <head>-Element anzusprechen.
Damit sich ein JavaScript nach dem vollständigen Laden der Seite selbst aktiviert, hat man früher im <body>-Element ein onload-Attribut notiert. Dieses enthielt JavaScript-Anweisungen, die nach dem vollständigen Laden der Seite ausgeführt wurden. Das Problem bei dieser Methode ist, dass wieder JavaScript-Code im HTML-Dokument steht, der in externe Dateien ausgelagert werden sollte.
Es gibt eine Eigenschaft des window-Objektes, die auch onload lautet, und in der eine Referenz auf eine Funktion abgelegt werden kann, um denselben Effekt wie das onload-Attribut im <body>-Element zu erreichen.
Anzeigebeispiel: So sieht's aus
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>Autostart</title>
<script type="text/javascript">
function fertig() {
alert("Das Laden hat ein Ende!");
}
window.onload = fertig;
</script>
</head><body>
<h1>Autostart</h1>
<p>Nach dem Laden müsste eine Meldung erscheinen.</p>
</body></html>
Im <script>-Bereich wird eine Funktion fertig definiert. Anschließend wird dem window-Objekt in die Eigenschaft onload eine Referenz auf die Funktion fertig gespeichert (man beachte das fehlende Klammernpaar nach fertig!). Dadurch wird erreicht, dass nach dem vollständigen Laden der Seite, die Funktion fertig ausgeführt wird.
Wenn Sie window.onload wie im obigen Beispiel verwenden, dann können Sie keine anderen Scripte einbinden, die auch diese Eigenschaft des window-Objektes nutzen, da Sie diesen Scripten die Startmöglichkeit verderben. Wie man es besser machen könnte, wird in einem der folgenden Beispiele behandelt.
Wie bereits besprochen kann ein simples Ändern von window.onload die Funktionalität anderer Scripte empfindlich stören. Darum sollten Sie vorher den Wert aus window.onload in eine Variable "retten", um ihn zu gegebener Zeit auszuführen, damit die Funktionalität anderer Scripte gewahrt bleibt.
Das folgende Beispiel zeigt, wie eine vorherige Funktion in window.onload nicht verloren geht:
function fertig() {
alert("Das Laden hat ein Ende!");
}
var oldWindowOnload = window.onload;
window.onload = function () {
if (typeof(oldWindowOnload) == "function") {
oldWindowOnload();
}
fertig();
};
In diesem Beispiel wird der Inhalt von window.onload in einer Variablen gespeichert, damit die in window.onload eventuell vorhandene Funktionsreferenz nicht verloren geht. Danach wird window.onload mit einer neuen Funktion gefüllt, die in obigem Code-Beispiel als anonyme Funktion direkt an Ort und Stelle definiert wird. In dieser anonymen Funktion wird zuerst mit dem typeof-Operator geprüft, ob in der Variablen auch wirklich eine Funktionsreferenz enthalten ist, um diese im Bedarfsfalle auszuführen (man beachte das Klammernpaar hinter oldWindowOnload()!). Danach wird die selbstdefinierte Funktion fertig ausgeführt.
Die ursprüngliche Reihenfolge der Funktionen bleibt gewahrt. Die anonyme neue Funktion kapselt sowohl eine bereits vorhandene Funktion als auch die zusätzlich auszuführende Funktion (im obigen Beispiel fertig) in einer Weise, dass die bereits vorhandene Funktion zuerst ausgeführt wird.
Sicherlich ist Ihnen aufgefallen, dass hier die Verwendung einer globalen Variable ebenso problematisch ist, wie sie das schon bei mehreren Fadern auf einer Seite war. Daher eignet sich hier der Einsatz eines Objektes, das den Inhalt von window.onload in einer Eigenschaft aufnimmt.
Wenn man alle bisherigen Überlegungen zusammenfasst, dann muss ein globales Objekt namens FaderFramework her: Dieses initialisiert sich nach dem Laden der Seite selbst, ist zu anderen Scripts kompatibel (indem es deren Autostart nicht zerstört), bindet eine zugehörige CSS-Datei und enthält eine Methode init, mit der sich Fader erstellen/einrichten lassen. Das sieht dann vorläufig so aus:
Anzeigebeispiel: So sieht's aus
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>Test1</title>
<script type="text/javascript">
var FaderFramework = {
oldWinOnLoad: false,
init: function (einstellungen) {
alert("Fader mit "
+ einstellungen.images.length
+ " Bildern soll für das Element mit der ID '"
+ einstellungen.id
+ "' eingerichtet werden!"
);
},
start: function () {
this.oldWinOnLoad = window.onload;
window.onload = function () {
if (typeof(FaderFramework.oldWinOnLoad) == "function") {
FaderFramework.oldWinOnLoad();
}
FaderFramework.onload();
};
},
onload: function () {
var e = document.createElement("link");
e.type = "text/css";
e.rel = "stylesheet";
e.href = "beispiel.css";
document.getElementsByTagName("head")[0].appendChild(e);
alert("Ladevorgang beendet.");
}
};
FaderFramework.start();
</script>
<script type="text/javascript">
FaderFramework.init({
id: "fader_test_1",
images: ["images/pic1.jpg", "images/pic2.jpg"]
});
</script>
</head><body>
<h1>Test unseres FaderFramework-Objektes</h1>
<p>Unser Objekt startet sich nach dem Laden selbst. Es sollte nach dem Laden eine Meldung erscheinen.</p>
</body></html>
Das Objekt FaderFramework wird als Objekt-Literal notiert. Das neue Objekt bekommt eine Eigenschaft oldWinOnLoad und die drei Methoden init, start sowie onload. Die Methode start richtet den bereits besprochenen Autostart-Mechanismus ein, indem sie window.onload entsprechend manipuliert, damit nach dem Laden der Seite die onload-Methode dieses FaderFramework-Objektes aufgerufen werden wird.
Die init-Methode nimmt Anfragen zum Einrichten neuer Fader-Objekte entgegen und ist hier mit einer vorübergehenden Funktionalität ausgestattet: Sie meldet die wesentlichen Daten, die an sie übermittelt wurden.
Die onload-Methode erzeugt ein neues <link>-Element, welches in den <head> des Dokuments eingebunden wird, damit eine CSS-Datei nachgeladen wird. Als CSS-Datei wird eine Beispiel-Datei benutzt, die lediglich zeigen soll, dass tatsächlich neue CSS-Eigenschaften nachgeladen wurden.
Nach seiner Definition wird das Objekt über start gestartet, damit es den Autostart einrichten kann.
Bei der Notation eines Objektliterals darf - wie bereits besprochen - am Ende einer Aufzählung kein Komma mehr stehen. Deshalb steht z.B. nach oldWinOnLoad, init und start ein Komma, am Ende der Funktionsdefinition von onload jedoch nicht. Dieser Umstand sorgt immer wieder als Fehlerquelle und sollte deshalb von jedem Script-Autor jedesmal peinlich genau überprüft werden.
Wie im obigen Beispiel zu sehen war, laufen die Teile des Scriptes zu unterschiedlichen Zeiten ab. Beispielsweise finden die init-Aufrufe noch während des Ladevorgangs statt - zu einem Zeitpunkt, an dem sich das Framework-Objekt selbst noch nicht initialisiert hat. Außerdem existiert zu diesem Zeitpunkt das <body>-Element noch nicht, sodass Fader-Objekte noch nicht angelegt werden können, da ein Zugriff auf das HTML-Element mit der angegebenen ID noch nicht möglich ist. Wie löst man nun dieses Problem der unterschiedlichen Zeitlichkeit auf? Es bleibt nur die Lösung, die Aufrufe vorübergehend abzuspeichern, um die tatsächliche Erstellung der Fader-Objekte zu einem späteren Zeitpunkt durchzuführen.
Was soll aber passieren, wenn ein Fader später erstellt werden soll, nachdem der Autostart abgearbeitet wurde und die "vorgemerkten" Fader bereits alle umgesetzt wurden? Ein solches Szenario wäre z.B. denkbar, wenn ein anderes Script Bilder aus einer Galerie ermittelt, um diese Bildergalerie durch eine Slideshow zu ersetzen (oder die Slideshow in einem Pseudofenster anzuzeigen). Hier muss der init-Aufruf so raffiniert reagieren, dass er diese beiden Zeitlichkeiten gleichfalls bewältigen kann.
Unser Framework erhält für diese Anforderungen eine neue Eigenschaft inits, in die die jeweiligen init-Aufrufe während des Ladevorgangs abgelegt werden, um später verarbeitet zu werden. inits wird ein Array werden, in dem die beim Funktionsaufruf von init übertragenen Daten abgelegt werden.
Nach dem Autostart wird diese Eigenschaft wieder entfernt, um dadurch der init-Methode zu signalisieren, dass künftige init-Aufrufe direkt in ein Fader-Objekt umzuwandeln sind, anstatt sie in inits nur vorzumerken, was ja nach dem Autostart nicht mehr existieren wird.
Anzeigebeispiel: So sieht's aus
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>Verschiedene Zeitlichkeiten auflösen</title>
<script type="text/javascript">
var FaderFramework = {
oldWinOnLoad: false,
inits: new Array(),
init: function (einstellungen) {
if (this.inits) {
alert("Fader (" + einstellungen.id + ") wird vorgemerkt");
this.inits[this.inits.length] = einstellungen;
} else {
alert("Fader (" + einstellungen.id + ") wird nun erzeugt");
}
},
start: function () {
...
},
onload: function () {
var i, fader, e = document.createElement("link");
...
alert("Ladevorgang beendet.");
fader = this.inits;
delete this.inits;
for (i = 0; i < fader.length; i++) {
this.init(fader[i]);
}
}
};
FaderFramework.start();
</script>
<script type="text/javascript">
FaderFramework.init({
id: "fader_test_1",
images: ["images/pic1.jpg", "images/pic2.jpg"]
});
FaderFramework.init({
id: "fader_test_2",
images: ["images/pic1.jpg", "images/pic2.jpg", "images/pic3.jpg"]
});
</script>
</head><body>
<h1>Verschiedene Zeitlichkeiten auflösen</h1>
<p>Das Framework empfängt während des Ladens der Seite Aufrufe...</p>
<p><a href="#" onclick="FaderFramework.init({id:'fader_extra',images:['images/pic1.jpg','images/pic2.jpg']});
return false;">Zusätzlichen Fader erzeugen</a></p>
</body></html>
Die Methode init speichert die übergebenen Daten (ein Objekt) in der Eigenschaft inits des FaderFramework-Objektes - aber nur, wenn diese Eigenschaft auch existiert, was über die if-Verzweigung geprüft wird. Im Funktionscode wird das Schlüsselwort this benutzt, da es zum einen sich auf das Framework-Objekt bezieht, in dem die Methode init definiert ist (an dieser Stelle haben this.inits und FaderFramework.inits denselben Effekt), und da es zum anderen wesentlich kürzer zu schreiben ist und auch die Lesbarkeit verbessert.
Der andere if-Zweig wird dann ausgeführt, wenn es keine Eigenschaft inits (mehr) gibt. An dieser Stelle soll die init-Methode wirklich einen Fader erzeugen lassen, wie in der alert-Meldung noch stellvertretend ausgegeben wird.
Die Methode onload bindet wieder eine CSS-Datei ins Dokument ein und nimmt sich dann jedes Element aus dem inits-Array vor, um damit einen Fader zu erzeugen. Dazu speichert sie zuerst den momentanen Inhalt von inits in der lokalen Variablen fader, um gleich danach die Eigenschaft inits mit Hilfe des Schlüsselworts delete aus dem FaderFramework-Objekt zu löschen. Dieser Schritt ist notwendig, da gleich danach in der for-Schleife für jeden einzurichtenden Fader die Methode init zum wiederholten Male aufgerufen werden soll, die jetzt aber keine Vormerkungen machen, sondern tatsächlich echte Fader-Objekte erstellen soll, was sie aber nur tun wird, wenn die inits-Eigenschaft nicht mehr im Framework-Objekt existiert.
Über den Link "Zusätzlichen Fader erzeugen" kann nach dem vollständigen Laden der Seite ein weiterer Fader eingerichtet werden, der auf identische Art und Weise über die init-Funktion eingerichtet werden kann.
In diesem Beispiel wird an verschiedenen Stellen stellvertretend nur eine Ausgabe mit alert notiert, da die dafür vorgesehene Konstruktor-Funktion, die weiter oben 
bereits besprochen wurde, den Rahmen dieses Code-Beispiels gesprengt hätte. Das folgende Beispiel wird aber beide Teile zusammenführen.
Wie bereits erwähnt ist das Schlüsselwort this kontextabhängig. In diesem Fall wird in der Methode start eine anonyme Funktion erzeugt und window.onload zugewiesen. Diese anonyme Funktion ist keine Methode von FaderFramework, weshalb man in ihr auch nicht mit this darauf verweisen kann. Darum steht in dieser anonymen Funktion FaderFramework.onload() tatsächlich ausgeschrieben.
Damit ist das Framework so weit, dass die oben erarbeitete Konstruktor-Funktion nun in das Framework-Objekt als eine Methode integriert werden kann. Damit bieten sich gleich noch weitere Möglichkeiten an: Ein Fader braucht nun nicht mehr als Objekt unter window einsortiert zu werden, sondern kann im Framework-Objekt abgespeichert werden. Außerdem kann er nach seiner Erstellung gleich gestartet werden, da das Framework den Fader garantiert erst nach dem vollständigen Laden der Seite erstellt.
Dafür wir ein weiteres Objekt faders als Eigenschaft des Framework-Objektes eingeführt, in dem die einzelnen Fader namentlich abgelegt werden, anstatt wie vorher unter window.
Anzeigebeispiel: So sieht's aus
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>Fader mit Autostart</title>
<script type="text/javascript">
var FaderFramework = {
oldWinOnLoad: false,
inits: new Array(),
faders: new Object(),
init: function (einstellungen) {
var fader;
if (this.inits) {
this.inits[this.inits.length] = einstellungen;
} else {
fader = new this.Fader(einstellungen);
if (fader != false && !this.faders[einstellungen.id]) {
this.faders[fader.id] = fader;
window.setTimeout(function () { fader.next(); }, fader.viewTime);
}
}
},
start: function () {
...
},
onload: function () {
var i, fader, e = document.createElement("link");
...
fader = this.inits;
delete this.inits;
for (i = 0; i < fader.length; i++) {
this.init(fader[i]);
}
},
Fader: function (einstellungen) {
if (!einstellungen.id || !document.getElementById(einstellungen.id)
|| FaderFramework.faders[einstellungen.id]
|| einstellungen.images.length < 2) {
return new Boolean(false);
}
...
this.fade = function (step) {
...
};
this.next = function () {
...
};
}
};
FaderFramework.start();
</script>
<script type="text/javascript">
FaderFramework.init({
id: "fader1",
images: ...
});
</script>
</head><body>
<h1>Fader mit Autostart</h1>
<p>Erster Fader: <img src="images/fliegen4.jpg" alt="Fliegen" id="fader1">.</p>
<p>Zweiter Fader: <img src="images/berge4.jpg" alt="in den Bergen" id="fader2">.</p>
<p><a href="#" onclick="FaderFramework.init({
id:'fader2',images:['images/berge1.jpg','images/berge2.jpg','images/berge3.jpg',
'images/berge4.jpg','images/berge5.jpg','images/berge6.jpg']});return false;">Zweiten Fader erzeugen und starten</a></p>
</body></html>
Das obige Beispiel vereinigt im Wesentlichen die bisherigen Code-Teile aus dem Framework und dem Konstruktor. Bereits bekannter Code wurde ausgelassen, wesentliche Veränderungen oder Ergänzungen sind hervorgehoben.
In der onload-Methode wird dieses Mal eine CSS-Datei eingebunden, die den CSS-Code enthält, der bereits in einem vorherigen Beispiel benötigt wurde. Danach werden alle vorgemerkten Initialisierungen aus der Eigenschaft inits in eine lokale Variable faders kopiert und anschließend die Objekteigenschaft inits aus dem Framework-Objekt entfernt.
Innerhalb einer for-Schleife werden dann alle vorgemerkten ursprünglichen init-Aufrufe abgearbeitet, indem sie dieser Methode erneut übermittelt werden. Da nun aber die inits-Eigenschaft im Framework-Objekt nicht mehr existiert, verhält sich die Methode init anders und erstellt nun die Fader-Objekte über den Konstruktor, anstatt sie in der bisherigen Objekteigenschaft inits vorzumerken. Dabei wird der Konstruktor mit den Einstellungen aus den init-Aufrufen "gefüttert". Sollte ein Fader erfolgreich erstellt worden sein, wird er unter seiner ID im Unter-Objekt faders abgelegt und mittels seiner next-Methode gestartet.
Der Konstruktor muss nun einen Fall mehr prüfen, bevor von einer erfolgreichen Erstellung eines Faders ausgegangen werden kann. Sollte nämlich bereits ein Fader mit der übermittelten ID angelegt worden sein, so muss der Konstruktor die Erstellung eines doppelten Faders verhindern und false (als Objekt!) zurückliefern. Daher prüft der Konstruktor, ob es in FaderFramework.faders bereits eine Eigenschaft (ein Fader-Objekt) mit dem Namen der übermittelten ID gibt. Auch hier kann nicht das Schlüsselwort this eingesetzt werden, da this hier auf das neu zu erstellende Fader-Objekt verweist. Daher wurde FaderFramework.faders ausgeschrieben.
Durch einen Klick auf den Link "Zweiten Fader erzeugen und starten" wird ein zweiter Fader erzeugt und gestartet. Da der im onload-Attribut notierte Funktionsaufruf die init-Methode des Frameworks mit passenden Parametern versorgt, wird dieser zweite Fader auch erfolgreich erzeugt, bei einem erneuten Klick jedoch nicht mehr. Hier greift die Prüfung im Konstruktor, die ein erneutes Erstellen eines bereits vorhandenen Faders verhindert.
Wie bereits angesprochen, muss ein Konstruktor immer ein Objekt zurückgeben, denn das ist der Sinn eines Konstruktors. Da in diesem Konstruktor eventuell kein erfolgreiches Fader-Objekt erstellt werden kann, soll "irgendwie" eine entsprechende Rückmeldung seitens des Faders erfolgen. Dazu wird entsprechend der Wert false als Boolean-Objekt zurück übermittelt. Eine simple Prüfung auf !fader (wie beispielsweise auch bei !einstellungen.id) wird aber hier nicht das erwartete Verhalten bewirken. Denn ein Boolean-Objekt wird, nur weil es ein Objekt ist und unabhängig von seinem Wert, in diesem Ausdruck als true gewertet, sodass zusammen mit dem Negations-Operator false herauskäme. Daher muss hier explizit auf fader != false (mit einem Ist-gleich-Zeichen!) geprüft werden, denn dabei wird der eigentliche Wert des Boolean-Objektes berücksichtigt.
Da der Konstruktor selbst eine Methode des Framework-Objektes geworden ist, wird er in der init-Funktion entsprechend mit var fader = new this.Fader(einstellungen) aufgerufen.
SELFHTML aktuell Artikel JavaScript Fader-Framework
© 2008 Impressum, für diese Seite: 
Felix.Riesterer@gmx.net
