peterS.: Weblog-Artikel: Der sinnvolle Einsatz von JavaScript

Beitrag lesen

Gruss Mathias,

ich habe von Dir sowohl im Weblog als auch im Forumsthread gestellte Fragen
einfach wild zusammengeklaubt und versuche nun schreibenderweis mal meine
Gedanken zu ordnen.

Eine der offenen Fragen ist die grundsätzliche Aufgabe und Rolle, die
JavaScript in der Webgestaltung spielen soll, und wie SELFHTML 9 dies
vermitteln soll.

Was ist sinnvoller JavaScript-Einsatz und welche Auffassung
vertritt SELFHTML?

Im Eröffnungs-Posting des Forumsthreads hast Du schon alle die Oberfläche
betreffenden Anwendungsbereiche genannt. Im Sinne eines defensiven
Programmieransatzes hast Du auch gleich noch das Stichwort "unobtrusive"
mit ins Spiel gebracht und die Kandidaten diesen Kriterien entsprechend
schon mal grob vorsortiert.

Für die neuen JavaScript-Kapitel wünsche ich mir, daß sowohl defensiver
Programmieransatz, als auch assistive/unterstützende, bereichernde/
"aufhübschende" Oberflächentechniken der "unobtrusive"-Schule als guter
Stil vor allem in den Beispielen vorgelebt werden.
Ein paar einführende kurze nicht polemisierende Sätze reichen meiner
Meinung nach vollkommen aus, um in jedermans Kopf zwei Gedankenpflöcke
zu schlagen und dazwischen diese Richtschnur zu spannen. Wer um die Regeln
weiß und diese nicht als Dogma, sondern als Anregung zum Selberdenken
begreift, wird sie gegebenenfalls auch ohne Bauchschmerzen zurechtbiegen
oder brechen können.

Wenn man sich das jetzige JavaScript-Kapitel ansieht, so fehlt ein klarer
theoretischer Unterbau, der dem Leser sinnvolle Anwendungsgebiete nennt
und entsprechende konkrete Beispiele vorstellt.

Welche konkreten Anwendungsbereiche von Javascript gibt es?
Wie kann sich dies im Aufbau des JavaScript-Kapitels niederschlagen?

Das Thema JavaScript sollte breit aufgefächert werden, um den vielen
möglichen Ansätzen, sich in diese Materie einzuarbeiten, möglichst gerecht
zu werden.

Ich plädiere daher für folgende Struktur:

  • Der Sprachkern

Dort sollte man sich unbedingt am Sprachkern nach "Standard ECMA-262
    3rd Edition - December 1999" abarbeiten. Auch die wenigen guten
    deutschsprachigen Bücher, deren jeweiliger Aufbau sich tatsächlich
    an den in diesem Dokument beschriebenen Sprachkern anlehnt, schaffen
    es meiner Ansicht nach nicht ganz, die Stärken dieser Sprache aus dem
    Verborgenen zu holen und angemessen zu beleuchten.
    Also ist es wichtig, genau an dieser Stelle über die Sonderstellung
    von "Object" und "Function" und deren Zusammenspiel im OO-Konzept von
    JavaScript/ECMAScript aufzuklären. Dort angelangt darf man sich auch
    gleich den unorthodoxen Vererbungsmöglichkeiten und dem dieser Vielzahl
    zugrundeliegenden Prototypenkonzept widmen, wobei man dann auch gleich
    etwas zur speziellen Art der Kapselung und zu "Closure"s im Allgemeinen
    sagen muss.

  • Der "Scripting Host" und seine Objekte

- Objekte, die von allen gängigen Browsern unterstützt werden
      (window, document, location, history, navigator, screen)...
    - ...und deren Inkonsistenzen.

An dieser Stelle darf dann auch darauf hingewiesen werden, daß sich in
    der Praxis sinnvolle Anwendungen meist auf "location" und "document"
    beschränken, womit zum nächsten Kapitel übergeleitet werden kann.

  • JavaScript und DOM-Zugriff

Ich bin mir nicht sicher, wo, wie und in welchem Umfang das Kapitel "DOM"
    abgehandelt werden soll. Zumindest DOM-spezifisches Scripting sollte hier
    mit reingepackt werden, damit man dann gleich übergehen kann zu:

  • JavaScript im Kontext von "DHTML"

also: JavaScript + DOM + CSS.

  • JavaScript im Kontext von "AJAX"

also: XMLHttpRequest + DHTML,
    oder eben auch nur: JavaScript + XMLHttpRequest + DOM.

andere Namensgebungsversuche:
      - RIAs/Rich Internet Applications(Macromedia),
      - DHTTP(David Flanagan)

  • Die Schulen des Scriptings

An dieser Stelle würde ich zuerst einmal nur auf Arbeitsgrundlagen wie
    - "Type Detection" (Sprachkern),
    - "Object Detection vs. Browser Sniffing" (Scripting Host) sowie
    - Weakleys Schichten-/Ansichten-Modell eingehen.
    Verständnis und Anwendung dieser Grundlagen führen fast schon automatisch
    zu ähnlichen, wenn nicht gar gleichen Arbeits- und Sichtweisen, wie sie in
    den Konzepten von "Graceful Degradation", "Unobtrusive JavaScript" und
    "Progressive Enhancement" beschrieben werden.

Mit einem Blick auf die vorgeschlagene Gliederung, läßt sich feststellen, daß
diese dem Entwicklungsprozess der in heutigen Browsern verfügbaren Technologien
folgt und aus ebendiesem Grund auch die 4. (JavaScript und DOM) und 3. (DHTML)
"Ansicht" nach Weakley abdeckt.

Ajax – ein Sonderfall der JavaScript-Anwendung?

Aus JavaScript-Perspektive sind "AJAX"-Anwendungen keineswegs Sonderfälle.
Alle in der Zeit vor "XMLHttpRequest" und "XML Save And Load" eingesetzten
Techniken für "hidden request"s bestätigen im nachhinein ja nur das schon
seit Jahren existierende Bedürfnis nach einer mächtigeren Schnittstelle für
Webapplikationen.
Zum Sonderfall wird "AJAX" aus dokumentenzentrierter Sicht, da es den
Weakleyschen Behavior-Layer der dritten und vierten Ansicht um die Möglichkeit
von außen nachladbarer Daten und Prozesslogik erweitert.
Ein voll ausgereiztes "request/response"-Objekte benutzt sein ansonsten
vollkommen leeres Dokument nur noch als Container für den Startprozess einer
durchaus komplexen Internet Anwendung.
Vom Konzept "Hypertext als Bindeglied zwischen Dokumenten" bleibt dann nichts
mehr übrig. Und doch sind solche Anwendungen völlig legitim.

Kennt ihr weitere (Anwendungs)Bereiche (von JavaScript) oder lassen sich
die Scripte, die ihr für besonders nützlich und beispielhaft erachtet,
bereits in diese Bereiche einordnen?

Du hast, glaube ich, alle Bereiche genannt. Den von Dir gewünschten
Beispielzoo sinnvoller Anwendungen möchte ich nur um das
"S5"-Präsentationsframework vom Team hinter Eric Meyer bereichern.
"Simple Standards-Based Slide Show System" fällt dann unter die Kategorien
"Outcome 3" und "Unobtrusive".

Gute Nacht - peterS. - pseliger@gmx.net

--
"Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive." - Douglas Crockford
ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]