SELFHTML Weblog - Ergänzung zur Dokumentation Übersicht

Mir gefällt der Artikel nicht besonders. Ich glaube, dass man das ganze auch wesentlich einfacher und vor allen Dingen zugänglicher realisieren könnte.

Inwiefern zugänglicher? Auf Einfachheit legt der Artikel eigentlich Wert, indem er schrittweise immer komplexere und gleichzeitig komfortablere und vielseitigere Lösungen vorstellt.

Nun ja, ich glaube, dass man doch zunächst eine Bilderliste in der Dokumentauszeichnung anlegen sollte, die später vom Skript in eine Slideshow umgewandelt wird. So könnten dann auch Leute, die JavaScript deaktiviert haben, auf die Bilder zugreifen.

Das Script ermöglicht beide Varianten je nach Zweck der Fader. Siehe auch das Einsatzbeispiel in einer Galerie.

Ein schönes Beispiel für "unobstrusive JavaScript".

Gefällt mir im Grunde, aber ich finde auch, dass es dem Anspruch "einen profunden Einstieg in die fortgeschrittene und zeitgemäße JavaScript-Programmierung zu bieten", noch nicht ganz gerecht wird.

Was mir dazu einfällt:

• Der Einsatz von Objekt-Literalen wird nicht konsequent durchgezogen: Gerade Anfängern könnte man doch erklären, dass var myArray = new Array(); synonym ist zu var myArray = []; und dass analog var myObject = new Object(); synonym ist zu var myObject = {};. Der Code würde so m.E. übersichtlicher werden.
• Um ein Objekt zurückzugeben, das zu false evaluiert, braucht man kein umständliches return new Boolean(false);, sondern einfach nur return null;, denn null ist gerade so ein Objekt.
• Was mich aber wirklich stört, ist die Tatsache, dass viele img-Elemente zum Einsatz kommen, die man umständlich ggf. erst erzeugt und dann in der DOM-Struktur ein- bzw. umhängt mit appendChild() und removeChild(), wo doch eigentlich nur genau zwei img-Elemente pro Fader völlig ausreichen, die man auch nicht jeweils im DOM-Baum umhängen muss, sondern lediglich deren src-attribute ändern, die man bequem in einem Array vorhält.
  
  Für eine Endlosschleife über so ein Array mit Bild-URIs muss man keinen Zähler einführen, den man am Ende wieder auf 0 setzt, sondern man kann statt dessen die Array-Elemente selbst rotieren, indem man dem Array eine Methode rot() gibt, z.B. so:

  imgURIs.rot = function (step) { /* rotiert Array-Elemente schrittweise, © Don P ;-) */
   step = (step||0) % (this.length||1);
   if      (step > 0) while (step--) this.unshift(this.pop());
   else if (step < 0) while (step++) this.push(this.shift());
  };
  

  Die nützliche Tatsache, dass man Objekte einfach um selber definierte Eigenschaften und Methoden erweitern kann, wird so anschaulich demonstriert und der Anfänger auch gleich mit wichtigen Array-Methoden bekannt gemacht.
• Erweiterungsfähig sind ja auch DOM-Elemente. Vielleicht könnte man einfach jedem neu erstellten span-Element eine Methode fade() geben, die den ganzen individuellen Fader darstellt, dessen Aufgabe es ist, die beiden einzigen im span-Objekt enthaltenen img-Elemente zu manipulieren, d.h. a) das enthaltene Array mit den URIs zu rotieren, b) die beiden ersten Array-Einträge als src-Attribute zuzuweisen und c) die Deckkraft des zweiten img-Elements einzustellen.

Habe mal ein bisschen mit dem Fader-Framework herumexperimentiert und bin zu m.E. besserem Code gekommen (bis dato ohne die Zufallsfunktion), der aber noch nicht völlig ausgereift ist. Ich denke, es geht *noch* besser.

Falls Interesse besteht, kann ich meinen Code mal zur Verfügung stellen. Vielleicht wollt ihr ja etwas davon benutzen, zumindest als weitere Anregung.

Gruß, Don P

Sorry für die seltsame Formatierung und die fehlende Unterschrift. Die Vorschau war korrekt.

Gruß, Don P

Ich persönlich finde diese Artikel interessant und instruktiv. Danke. Gruß.

Hallo Don P,

Du nennst interessante Ideen zur Verbesserung meines Artikels. Was die Vereinfachung des Codes angeht, stimme ich Dir zu. Das Rotieren von src-Attributwerten ist sicherlich einfacher, als Elemente im DOM aus- und an anderer Stelle wieder einzuhängen. Aber so "unterrichtet" der Artikel Anfänger auch in diesen Dingen - auch wenn sie für die Lösung der gestellten Aufgabe vielleicht unnötig umständlich sind.

Vielleicht sollte man einen "Teil 2" zu diesem Artikel ergänzen, in dem die vorgestellten Lösungswege neu betrachtet, kritisch hinterfragt und dann eleganter gelöst werden, um das bereits vorhandene Wissen um die möglichen Techniken (und Programmierwege) weiter auszureifen (oder gar weiter zu abstrahieren)? Gerade die Idee, DOM-Elementobjekte mit neuen Methoden zu erweitern wäre ein Ansatz, den mein Artikel vermeidet.

Was meinst Du? Hättest Du Lust einen Ergänzungsartikel zu schreiben?

Liebe Grüße,

Felix Riesterer.