vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisFeedbacknächstes Kapitel


Woche 1

Tag 2

Das Wesen von JavaScript

Nach dem doch sehr grundlegenden und theoretischen ersten Tag wollen wir nun zu JavaScript als Hauptthema kommen. JavaScript ist wie bereits angedeutet die ideale Ergänzung zu HTML, wenn es gilt, statische HTML- Seiten zu dynaminisieren, den umgebenden Browser zu programmieren oder auf Objekte vielfältiger Natur zugreifen zu können. Wir wollen am zweiten Tag Folgendes behandeln:

Was ist JavaScript?

Als das WWW entstand, gab es nur HTML, um Webseiten zu beschreiben. HTML ist das Rückgrat des WWW und es wird wohl auch in Zukunft so bleiben. HTML ist nicht das ganze Web, aber ohne HTML gibt es überhaupt kein Web. Keine (!) der anderen Technologien (Grafiken, Videos, Sounds, Scripte, ActiveX-Controls, Java-Applets usw.) ist notwendig im Web. Das Web an sich funktioniert - wenn es sein muss - auch nur mit reinem HTML. Jede der anderen Technologien benötigt HTML, um sich darin zu verankern. Ob es ein Script in einer Webseite ist - das Script wird Bestandteil einer HTML-Seite sein oder sich zumindest darin verankern. Ob es ein Java-Applet ist - es ist im Web nur im Rahmen einer Referenz in einer HTML-Seite lauffähig. Analog verhält es sich mit anderen Techniken.

Ein Vergleich aus der realen Welt kann die Bedeutung von HTML verdeutlichen - ein Vergleich mit einem Haus. HTML ist dabei das Mauerwerk samt Fundament und Dach. Ohne einen Verputz außen und Tapeten innen ist das Haus zwar recht hässlich, aber es hält den Regen ab, schützt vor Kälte, man kann Dinge einräumen, es lässt sich abschließen und was so ein unausgestattetes Haus noch so leistet. Grafiken samt ihrer Spielarten könnte man mit dem Verputz, den Tapeten und auch den Bildern an der Wand vergleichen. Ohne das Mauerwerk sinnlos, aber darauf verankert eine ästhetische Verfeinerung. Sonstige Multimedia- Techniken wie Sound und Animationen stehen für Radios, Videos und Fernsehgeräte. Scripte und aktive Programme wie Java-Applets oder ActiveX-Controls stehen in unserem Vergleich beispielsweise für Zusatztechniken wie Telefon, Fax oder Computer, aber auch allgemeine Bequemlichkeiten wie elektrische Garagentüröffner, Kühlschränke, Geschirrspüler, Waschmaschinen, Kaffeemaschinen1 etc. Alles Dinge, die das Wohnen in einem Haus komfortabel machen, die Funktionalität erweitern, es bequemer und besser machen. Aber allesamt sind ohne das Haus, worin sie eingebaut werden, woher sie wichtige Dinge wie Strom beziehen, absolut nutzlos.

Genauso würde das Web viel an Faszination und Bequemlichkeit verlieren, wenn man auf ergänzende Techniken verzichten würde. Die Möglichkeiten von reinem HTML stoßen sehr bald an Grenzen und werden mehr und mehr durch verschiedene Zusatztechnologien erweitert. Teilweise basieren diese Erweiterungstechnologien direkt auf HTML, etwa Style Sheets.

Auch XML (Extensible Markup Language) ist ein Begriff, der in der letzten Zeit oft in Zusammenhang mit HTML genannt wird. Genau genommen hört man immer öfter, dass HTML von XML in Kürze abgelöst werden soll. XML hat wie HTML seine Wurzeln in SGML, nur eine andere Aufgabe. Streng genommen kann XML all das, was HTML auch kann, und mehr, aber das ist beileibe nicht alles. XML als Erweiterung von HTML zu sehen, fasst das Potential von XML nicht richtig.

XML ist eine so genannte Metasprache, mit deren Hilfe eine eigene, neue Dokumentenbeschreibungssprache definiert werden kann. Auch XSL (Extensible Stylesheet Language) ist eine verwandte in Verbindung zu HTML zu sehende Erweiterung. Im Grunde ist XSL das für XML, was CSS für HTML ist - eine Style-Sheet-Sprache, um visuelle Angaben in einem Dokument umzusetzen (dies nennt man eine physische Auszeichnung). XML kümmert sich nur um inhaltliche und strukturelle Definitionen eines Dokuments - eine so genannte semantische Auszeichnung.

Die Behauptung, dass XML und XSL HTML bald ablösen werden, muss trotz der Leistungsfähigkeit kritisch hinterfragt werden. Mit beiden Techniken lässt sich die Leistungsfähigkeit von HTML zwar erheblich erweitern, aber XML und XSL sind nicht ganz so einfach zu lernen. Zudem lässt die Unterstützung von XML/XSL durch geeignete Interpreterprogramme ziemlich zu wünschen (in den neusten Browser-Versionen von Microsoft und Netscape sind erste Ansätze vorhanden). Es scheint so, dass XML und XSL zwei der vielen Web-Technologien sind, um die erst viel Wind gemacht wird, die dann aber trotz ihrer unbestrittenen Vorteile nicht so recht aus den Startlöchern kommen. Und selbst wenn - sie werden keine direkte Ablösung von HTML sein, sondern nur eine Ergänzung, deren Haupteinsatzgebiet wahrscheinlich die Business-to-Business-Anwendungen im Rahmen des E-Commerce (also dem elektronischen Datenaustausch zwischen Unternehmen zur Abwicklung von Geschäftsvorgängen) sein werden.

Eine der wichtigsten Erweiterungen von HTML sind die Scriptsprachen, von denen es zahlreiche Versionen gibt. Beispielsweise Perl (Practical Extraction and Report Language), VBScript oder eben JavaScript. Dabei muss man zwischen Server-seitigen und Client-seitigen Scriptsprachen unterscheiden, worauf wir etwas weiter unten genauer noch eingehen. Das im Internet praktizierte Client-Server-Prinzip erlaubt die Aufteilung von Funktionalität auf beide beteiligten Partner. Sowohl der Client als auch der Server können über Scripte programmiert werden. Es existieren sowohl auf der Clientseite wie auf Serverseite die unterschiedlichsten Scriptsprachen. Viele davon lassen sich sowohl auf Clientseite wie auf Serverseite einsetzen oder haben zumindest definierte Schnittstellen auf beiden Seiten. Auf den meisten Servern stehen Perl-Interpreter zur Verfügung. Auf Clientseite werden im Web im Wesentlichen zwei (genau genommen drei) Sprachen unterstützt. Das sind eben JavaScript bzw. JScript sowie VBScript - letztere weitgehend begrenzt auf den Internet Explorer.

Bei den Scriptsprachen handelt es sich immer um Interpretersprachen, die von irgendeinem Interpreter interpretiert werden müssen. Diesen Interpreter stellt das umfassende Programm bereit, in das Scripte geladen werden. Im Fall von JavaScripten beim Anwender ist das der Browser, der einen internen JavaScript-Interpreter (bzw. einen JScript-Interpreter im Fall vom Internet Explorer) bereitstellt.

JavaScript

JavaScript ist eine an Java angelehnte, offene, plattformunabhängige Scriptsprache. Entwickelt wurde JavaScript von Netscape in einer Kooperation mit Sun Microsystem sowie einigen weiteren Partnern. Ursprünglicher Einsatzzweck von JavaScript war die Erweiterung des Navigator 2.0 um Steuerungsmöglichkeiten für diesen Browser aus einer Webseite heraus. Diese mit dem Navigator 2.0 1995 erstmals veröffentlichte Scriptsprache wurde zuerst Mocha, dann LiveScript und letztendlich JavaScript (um eine Anlehnung an Java zu verdeutlichen) genannt.

JavaScript erlaubt die Notation von Scripten direkt in eine HTML-Seite (oder zumindest die Referenz darauf - was das genau bedeutet, folgt in späteren Lektionen). Diese werden dann von einem Interpreter ausgeführt, der von dem Browser automatisch aufgerufen wird, wenn er den entsprechenden Befehl dazu in der Webseite vorfindet. JavaScript- Anweisungen sind damit eine reine Klartexterweiterung des HTML-Codes und nur als eingebundener Bestandteil eines HTML-Gerüsts zu verwenden.

JavaScript ist seit seiner Entstehung durch mehrere Versionszyklen gegangen. Derzeit gibt es JavaScript als Core JavaScript (also purer Syntaxstandard) bereits in der Version 1.4, aber die ist noch nicht als Standard im Web akzeptiert und von Browsern unterstützt, sodass die Version 1.3 als relativ weit unterstützte Fassung unsere Referenzversion sein soll. Auf Serverseite gibt es derzeit JavaScript in der Version 1.5, wobei man festhalten sollte, dass serverseitiges JavaScript sich in einigen Details von clientseitigem unterscheidet. Das soll für uns aber keine Rolle spielen - wir bleiben sowieso auf Clientseite.

Auch die Version 1.3 ist noch nicht in allen Browsern integriert. Beispielsweise unterstützt der Opera-Browser bis zur Version 3.6 (die bis Mitte 2000 aktuelle Version) sogar nur JavaScript 1.1. Dies ist aber für Einsteiger kein sonderliches Problem, denn bereits die Leistungsfähigkeit von JavaScript 1.1 erlaubt, viele interessante Funktionalitäten zu programmieren. Im Anhang finden Sie eine Auflistung, welcher Browser welche Version von JavaScript bzw. JScript unterstützt. Grundsätzlich muss zudem beachtet werden, dass für nahezu alle Sprachzyklen von JavaScript kein einziger Browser den offiziellen Standard vollständig unterstützt! Es gibt immer bestimmte Konstellationen, wo es Probleme geben kann. Tests auf verschiedenen Browser sind deshalb leider unumgänglich - insbesondere bei Anweisungen ab JavaScript 1.2.

VBScript

Eine zeitweise als großer Gegenspieler von JavaScript gefeierte Scriptsprache ist die von Microsoft aus Visual Basic entwickelte Sprache VBScript. Der Ursprung in Visual Basic sollte von vornherein vielen Einsteigern das Erlernen von VBScript erleichtern, denn Basic- bzw. Visual- Basic-Grundkenntnisse sind weit verbreitet. VBScript wurde gegenüber seinem Vorfahren erheblich vereinfacht, gilt aber durch seine weitgehende Beschränkung auf das Windows-Betriebssystem mit INTEL-basierenden Prozessoren und dem Internet Explorer als Clientprogramm und damit einhergehende Optimierung im Hinblick auf die WINTEL-Plattform dort als leistungsfähiger als JavaScript.

Die Optimierung der plattformabhängigen Leistungsfähigkeit scheint jedoch nicht den gewünschten Erfolg mit sich zu bringen. Die Akzeptanz von VBScript ist beileibe nicht so groß wie die von JavaScript. Dies kann man auf mehrere Gründe zurückführen:

JavaScript und Java

JavaScript wird als eine an Java angelehnte, offene, plattformunabhängige Scriptsprache bezeichnet. Dies und der im Namen vorkommende Begriff Java führt dazu, dass JavaScript oft mit Java verwechselt oder als Ersatz gesehen wird. Dies ist allerdings falsch. Java ist viel leistungsfähiger als jede Scriptsprache (und die meisten Programmiersprachen), jedoch auch viel komplizierter zu lernen. Für Java gibt es ganz andere Anwendungen als für Scriptsprachen wie JavaScript.

Java ist eine weitgehend betriebssystem- und hardwareunabhängige, objektorientierte Programmiersprache beziehungsweise ganze Entwicklungsplattform, die zwar einen Schwerpunkt im Bereich Internet/ Intranet hat (mit den Java-Applets), den Haupteinsatzzweck aber im Bereich der datenbasierenden Konsumerelektronik finden soll (die Programmierung von allen Geräten des täglichen Lebens, die mit einem Prozessor ausgestattet sind oder in Zukunft ausgestattet werden können - vom Videorecorder bis zum Kühlschrank). Daneben gilt Java als sehr sicher und geeignet für Anwendungen, die in einer heterogenen Netzwerkumgebung ablaufen sollen. Viele Aktionen im Bereich des Online- Bankings, des elektronischen Zahlungsverkehrs oder sonstiger sensibler Datenkommunikation beruhen auf Java.

Abbildung 2.1:  Ein Java-Applet, welches im Bereich Online-Broking verwendet wird

Mit Java lassen sich vollständige Programme entwickeln (im Gegensatz zu Scripten, die nur bereits fertige Programme steuern und nutzen). Sowohl in Form von Java-Applets, die mit HTML-Anweisungen in eine Webseite integriert werden und auch nur dort lauffähig sind als auch als vollständig eigenständige Applikationen, die im Gegensatz zu den Applets keinen Container wie einen Browser mehr benötigen.

Entwickelt wurde Java von Sun Microsystems als eine Sprache, die von der Syntax C/C++ sehr ähnlich ist. Java-Quellcode wird durch den Java- Compiler in ein plattformunabhängiges Bytecode-Format übersetzt, das dann auf der Zielmaschine durch die so genannte Java Virtual Machine (JVM) interpretiert wird.

Die Java Virtual Machine ist eine Interpreterschnittstelle zwischen dem Java-Bytecode auf der einen und der zugrunde liegenden Hardwareplattform und dem Betriebssystem auf der anderen Seite. Die JVM muss auf jedem Rechner bzw. programmierbaren Gerät vorhanden sein, welcher Java-Anwendungen ausführen möchte. Sie realisiert die Umsetzung des Bytecodes in ausführbare Prozessorbefehle. Die Java Virtual Machine kennt die Spezifika der jeweiligen Hardware, auf der sie läuft, und kann so auf die Eigenheiten eines bestimmten Prozessortyps und der restlichen Hardware Rücksicht nehmen.

Die offizielle Definition von Sun Microsystems für Java lautet folgendermaßen:

Java: eine einfache, objektorientierte, dezentrale, interpretierte, stabil laufende, sichere, architekturneutrale, portierbare und dynamische Sprache, die Hochgeschwindigkeits-Anwendungen und Multithreading unterstützt.

Was kann man mit JavaScript tun?

JavaScript erweitert eine Webseite auf vielfältigste Art und Weise. Insbesondere kann der Besucher einer Seite in einen Dialog mit der Webseite einbezogen werden, statt sich die Seite nur anzuschauen. Dies können bewusste Dialoge sein - etwa Rückfragen nach einem Passwort oder nach dem Namen des Anwenders, aber auch die Kontrolle von Eingabe in einem Webformular. Aber auch Hintergrundaktionen, die beispielsweise eine Art Dialog mit dem Browser des Anwenders oder seiner Plattform führen - etwa die automatische Abfrage des Browserstyps und entsprechende Reaktion darauf, das Lesen und Schreiben von Cookies, die Abfrage der History des Browsers, die Abfrage der Systemzeit usw. Mit JavaScript kann man auch Berechnungen durchführen, beispielsweise eine Umrechnung zwischen DM und EURO, die Summierung der Gesamtkosten einer Bestellung einzelner Artikel oder die Ermittlung der optimalen Größe eines anzuzeigenden Bildes. Grundsätzlich lassen sich mit JavaScript auch Vorgänge automatisieren, welche ein Anwender sonst in mehreren Schritten manuell durchführen müsste (etwa das gleichzeitige Laden von mehreren Webseiten auf einen Mausklick, was beispielsweise bei einer Framestruktur oft sinnvoll ist).

JavaScript beinhaltet einen internen Befehlssatz, eine Syntax und eine definierte Struktur, mit denen diverse Objekte rund um den Browser kontrolliert werden können. Ein kontrollierbares Objekt ist beispielsweise der Browser selbst. Aber auch andere Objekte lassen sich mit Scripten beeinflussen. JavaScript kann beispielsweise zur Kontrolle von Bestandteilen einer Webseite, Java-Applets und anderen Objekten verwendet werden. Eigentlich ist es so, dass Client-seitige Scriptsprachen im Wesentlichen den relativ dummen Browser intelligenter machen. In modernen Browsern ist die Nutzung einer oder mehrerer Scriptsprachen standardmäßig integriert. So gut wie immer wird JavaScript verstanden.

Grundsätzlich kann man die Hauptfunktion von Scriptsprachen, die im Rahmen einer Webseite verwendet werden, so beschreiben: Sie erlauben eine Verlagerung von solcher Funktionalität zu dem Browser, die bei einer reinen HTML-Seite von einem Anwender mehrere zusätzliche Aktionen erfordern würde oder auf dem Server abgearbeitet werden müßte. Solche Client-seitigen Scripte erlauben einem Webbrowser, auf eine intelligente Weise mit Situationen, die sonst eine Aktion auf dem Webserver erforderlich machen würden, umzugehen, ohne erst eine Rückfrage beim Server durchzuführen. Wesentlicher Effekt ist damit eine Beschleunigung vieler Vorgänge, da der Browser wie gesagt keine Anfrage an den Server schicken und die Antwort nicht abwarten muss. Um diesen Postiveffekt genauer zu verstehen, muss man sich das Alternativverfahren unter reinem HTML verdeutlichen. Der konventionelle Weg einer eventuell erforderlichen Kommunikation zwischen dem Besucher einer Webseite und dem Server, wo die Seite gespeichert ist, erfolgt meist über eine Technik, die CGI heißt.

CGI ist die Abkürzung für »Common Gateway Interface«, was übersetzt »Allgemeine Zugangsschnittstelle« bedeutet und einen Prozess zur Datenkommunikation auf einem Server beschreibt. CGI ist eine Schnittstelle für einen Client zu einem Serverprogramm, über welche die Übergabe von Parameterwerten an Programme oder Scripte auf einem Server erfolgen kann. Dort werden die übergebenen Werte verarbeitet und bei Bedarf wird eine Antwort (meist ein HTML-Dokument) an den Client generiert. CGI ist keine Programmiersprache, sondern ein Protokoll zur plattformübergreifenden Standardisierung von so einem Datenaustausch. CGI-Scripte können in jeder Sprache erstellt werden, die Scripte erstellen kann und von der auf dem jeweiligen Server ein passender Interpreter vorhanden ist. Die meistverbreitete Sprache zur Erstellung von Scripten ist Perl (die Sprachspezifikation ist unter http://www.perl.com zu finden), aber auch nahezu alle anderen Sprachen eignen sich, wenn sie Scripte erstellen können und auf dem Zielserver ein passender Interpreter vorhanden ist (dazu zählt auch JavaScript).

Allgemein stellt CGI einen Mechanismus zur Verfügung, bei dem auf dem Client erfasste Daten (beispielsweise über ein HTML-Formular) zu einem Server geschickt werden können. Dieser leitet diese Daten zu einem Server-seitigen Programm/Script weiter, wo sie verarbeitet werden. Anschließend geht die Antwort zurück zum Client.

Ein klassischer Prozess über das Client-Server-Prinzip mittels CGI und einem Browser als Clientprogramm läuft nach folgendem Muster ab:

  1. Aktionen, die im Rahmen einer im Browser geladenen Webseite ausgelöst werden (etwa der Klick auf eine Schaltfläche in einer Webseite im Rahmen eines Formulars), müssen ungeprüft zu dem Server zurückgeschickt werden.
  2. Auf dem Server werden sie verarbeitet.
  3. Anschließend wird das daraus ermittelte Ergebnis als Antwort zu dem Client zurückgeschickt.

So eine Vorgehensweise hat zahlreiche Nachteile.

Gerade bei fehlerhaften Daten wird so viel Zeit und Kapazität verbraucht. Ein Beispiel ist etwa ein Formular, in dem die Eingabe eines nummerischen Wertes (etwa Geldbetrages) erfolgen soll. Wenn nun ein Anwender dort statt Zahlen Buchstaben einträgt, hat man unter HTML keinerlei Kontrollmöglichkeit. Die fehlerhaften Daten werden ungeprüft zum Server geschickt, der leitet sie weiter an seine zugeordnete Prüfungsroutine und erst das Server-seitige Programm bemerkt den Fehler. Es generiert eine Fehlermeldung, die dann als Antwort zurück zum Browser geschickt wird. Keine ideale Vorgehensweise - insbesondere, wenn die ganze Kommunikation mehrfach rund um die Welt geschickt werden muss.

Sehr sinnvoll wäre es, wenn der Fehler bereits vor dem Abschicken der Daten beim Client bemerkt werden würde. Solche Funktionalität, die auch ohne Serverkontakt funktioniert, kann mit JavaScript auf den Client übertragen werden. Etwa wie in unserem Beispiel eine Typüberprüfung eines Eingabefeldes.

Erste JavaScript-Beispiele

So langsam ist es Zeit, einige JavaScript-Beispiele durchzuspielen. Dabei wollen wir bewusst auf die exakte Erklärung der genaueren Hintergründe verzichten, um Sie nicht noch länger auf die - theoretische - Folter spannen zu müssen. Folgen Sie einfach den Anweisungen und tippen Sie den jeweiligen Quelltext der Beispiele ab.

Starten Sie als Erstes einen Editor. Dies kann sogar der im Windows- Zubehör mitgelieferte Editor Notepad sein (Sie finden ihn in der Regel unter dem Startmenü, Programme, Zubehör).

Eine gute und sicher bequemere Alternative für einen reinen Texteditor ist beispielsweise der Editor Super NoteTab, den Sie als Freeware unter http://www.unige.ch/sciences/terre/geologie/fookes/ finden.

Beispiel 1:

Geben Sie im Editor den nachfolgenden Quelltext ein (beachten Sie bitte unbedingt Groß- und Kleinschreibung - auch wenn es teilweise nicht relevant ist):

Bitte trennen Sie bei den Beispielen in Hochkommata eingeschlossene Texte - so genannte Strings oder Zeichenketten - nicht durch Zeilenumbruch. Auch wenn dies im abgedruckten Quelltext aus Satzgründen so notwendig ist - im Editor sollten Sie das vermeiden. Dies gilt für alle Quelltexte im Buch.

<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
function schreibeSeite()
{
var datum = new Date();
var tag = datum.getDate();
var monat = datum.getMonth() + 1;
var jahr = 2000 + (datum.getYear()%100);
var name = prompt(
"Geben Sie bitte Ihren Namen ein","");
document.write('<HTML>');
document.write('');
document.write('<HEAD>');
document.write(
'<title>Meine erste JavaScript-Homepage</title>');
document.write('</HEAD>');
document.write('<BODY>');
document.write(
'<H1 align=center>Herzlich Willkommen</H1>');
document.write('<H3 align=center>');
document.write(name);
document.write('</H3>');
document.write('<H4 align=center>');
document.write('Heute, am ');
document.write(tag);
document.write('.');
document.write(monat);
document.write('.');
document.write(jahr);
document.write(' wartet auf Sie hier wieder ein spannendes Programm</H4>');
document.write('</BODY>');
document.write('</HTML>');
}
</SCRIPT>
</HEAD>
<BODY onLoad="schreibeSeite()">
</BODY>
</HTML>

Speichern Sie die Datei unter dem Namen ErsteSeite.htm und starten Sie diese dann mit einem Doppelklick darauf in ihren Standardbrowser (oder eine Ihnen sonst genehme Art).

Das Beispiel (wie auch die folgenden) zeigt die dynamische Erstellung einer Webseite mittels JavaScript, in der Informationen berücksichtigt werden, die erst zum Zeitpunkt des Ladens der Seite bekannt sein können. Das sind in diesem Fall das aktuelle Datum und der Name, mit dem sich ein Besucher vor dem Laden der Webseite identifiziert. Diese Informationen werden in Variablen zwischengespeichert. Zuerst sollte ein Eingabefenster erscheinen, in dem der Anwender aufgefordert wird, seinen Namen einzugeben.

Variablen gehören zu den absolut grundlegenden Elementen einer jeden Programmier- oder Scriptsprache. Ohne Variablen kann man nicht - sinnvoll - programmieren. Wer bereits in irgendeiner Sprache Programme oder Scripte erstellt hat, wird sie kennen. Aber auch aus der Schulmathematik dürfte vielen Lesern zumindest der Begriff geläufig sein.

Technisch gesehen bezeichnen Variablen Stellen im Hauptspeicher, in denen irgendwelche Werte temporär gespeichert werden können. Dazu haben sie einen Namen (einen Bezeichner), über den sie später im Programm oder Script wieder verwendet werden können sowie einen so genannten Datentyp (eine zugeordnete Information, was für eine Art von Information in der Variablen gespeichert wird, also beispielsweise eine Zahl oder ein Text).

Abbildung 2.2:  Die Eingabe vor dem Aufbau der Seite

Der Name der Variablen wird anschließend verwendet, indem mit dieser Angabe, dem aktuellen Tagesdatum und einigen vorgefertigten Textbausteinen dynamisch eine Webseite geschrieben wird. Dabei werden die jeweils notwendigen HTML-Befehle ebenso per JavaScript in die Seite geschrieben.

Abbildung 2.3:  Die dynamisch mit JavaScript aufgebaute Seite mit spezifischen Informationen

Diese oder eine ähnliche Technik wird allgemein von Serverprogrammen verwendet, wenn dynamische Webseiten zu erzeugen sind. Gute Beispiele dafür sind Suchmaschinen, die auf Grund einer Eingabe (eines oder mehrerer Suchbegriffe) dynamisch eine neue Webseite mit den jeweils spezifischen Ergebnissen erzeugen.

Bei dem Beispiel verwenden wir eine JavaScript-Funktion, die beim Laden der Webseite aufgerufen und ausgeführt wird.

Eine Funktion können Sie sich erst einmal als die Zusammenfassung von mehreren Anweisungen vorstellen, die mit einem Namen (einem Bezeichner) versehen wird und über den die Gruppe von Anweisungen wieder aufgerufen werden kann. Eine Funktion wird auch erst bei einem solchen Aufruf ausgeführt. Dort, wo sie definiert wird, ist sie gegen eine Ausführung abgeschottet. Wir werden den Begriff später noch genauer verfolgen.

Der Opera-Browser kann in einigen Versionen bei diesen Beispielen Probleme machen. Dies ist aber ein spezifisches Browser-Problem und kein Fehler in den Scripten.

Beispiel 2:

Das nächste Beispiel demonstriert, wie man unter JavaScript Berechnungen durchführen kann. Es soll nur eine kleine Kalkulation durchgeführt werden - eine Zeitberechnung, wie lange es dauert, wenn man mit einer gewissen Geschwindigkeit eine bestimmte Distanz zurücklegt. Nennen Sie die Datei Wegberechnung.htm:

<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
function wegBerechnung()
{
var entfernung = prompt("Geben Sie bitte die Entfernung in Kilometer ein, die Sie zurücklegen wollen","");
var geschwindigkeit = prompt("Wie hoch ist Ihre Durchschnittsgeschwindigkeit in Km/h?","");
var ergebnis = entfernung/geschwindigkeit;
document.write('<HTML>');
document.write('');
document.write('<HEAD>');
document.write('<title>Wegberechnung</title>');
document.write('</HEAD>');
document.write('<BODY>');
document.write('<H1 align=center>Wegberechnung</H1>');
document.write('<H4 align=center>');
document.write('Für eine Stecke von ');
document.write(entfernung);
document.write(' Kilometer benötigen Sie bei einer Durchschnittsgeschwindigkeit von ');
document.write(geschwindigkeit);
document.write(' Km/h ');
document.write(ergebnis);
document.write(' Stunden.</H4>');
document.write('</BODY>');
document.write('</HTML>');
}
</SCRIPT>
</HEAD>
<BODY onLoad="wegBerechnung()">
</BODY>
</HTML>

Beachten Sie bitte, dass dies nur ein ganz einfaches Beispiel ist. Es ist weder gegenüber einer Division durch 0 noch fehlerhafte Eingaben wie Buchstaben abgesichert. Auch wenn das Ergebnis kleiner 1 ist, wird die führende Null nicht angezeigt.

Beim Laden der Seite wird zuerst eine Eingabe der Entfernung abgefragt. Diese Information wird in einer entsprechenden Variablen gespeichert.

Abbildung 2.4:  Die zurückzulegende Entfernung in Kilometern

Danach geben Sie die Durchschnittsgeschwindigkeit ein. Auch diese Information wird in einer weiteren Variablen gespeichert.

Abbildung 2.5:  Die dynamisch mit JavaScript aufgebaute Seite mit den berechneten Daten

Abbildung 2.6:  Die Durchschnittsgeschwindigkeit

Aus beiden Werten wird die Zeit berechnet, welche für die Strecke benötigt wird (mit dezimalem Anteil der Minuten). Diese Information wird in einer dritten Variablen gespeichert und in der nun dynamisch generierten Webseite verwendet.

Beispiel 3:

Mit JavaScript kann man einiges über die Plattform des Besuchers herausbekommen - das erste Beispiel fragt ja bereits die in dem Computer eingestellte Systemzeit ab. Das dritte Beispiel (Plattform.htm) soll nun den Browser des Anwenders abfragen und den verwendeten Browser in der Webseite anzeigen.

Beachten Sie, dass die hier abgefragten Informationen nicht von jedem Browser bzw. jeder Plattform vollständig und teilweise nicht einmal korrekt angegeben werden.

<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
function spionage()
{
document.write('<HTML>');
document.write('<HEAD>');
document.write('<title>Wer bist Du</title>');
document.write('</HEAD>');
document.write('<BODY>');
document.write('<H1 align=center>Big Brother is watching you</H1>');
document.write('<H4 align=center>');
document.write('Herzlich willkommen ');
document.write('</H4>');
document.write('<H4 align=center>');
document.write('Ich weiss bereits einiges über Sie');
document.write('</H4>');
document.write('<P>Sie verwenden folgenden Browser: ');
document.write(navigator.appCodeName + ', ' + navigator.appName + ', '
  + navigator.appVersion);
document.write('<P>Ihre eingestellte Sprache ist ');
document.write(navigator.language + '.');
document.write('<P>Ihr Betriebssystem ist ');
document.write(navigator.platform + '.');
document.write('</P>');
document.write('</BODY>');
document.write('</HTML>');
}
</SCRIPT>
</HEAD>
<BODY onLoad="spionage()">
</BODY>
</HTML>

Das Beispiel kommt diesmal vollkommen ohne Variablen aus, sondern verwendet die direkte Auswertung von Informationen, die jeder Browser über sich preisgibt.

Abbildung 2.7:  So outet sich der Internet Explorer 5.01 unter Windows NT 4.0

Abbildung 2.8:  Der Netscape Navigator 6.0 in der englischen Version unter Windows NT 4.0

Abbildung 2.9:  Das gibt der Netscape Navigator 4.7 unter Windows NT 4.0 bekannt

Beispiel 4:

Das dritte Beispiel (Plattform.htm) verwendet wieder eine JavaScript- Funktion, die beim Laden der Webseite automatisch geladen wird. Mit der hier verwendeten Form des Scriptaufrufs hat der Opera-Browser unter Umständen Probleme, wie bereits etwas weiter oben angedeutet. Deshalb wollen wir das Beispiel geringfügig umbauen, sodass dieses Problem umschifft wird (dies ist keine Lösung für jeden Fall, sondern nur für diese spezielle Situation). Wesentliche Änderung ist die direkte Notation der Scriptanweisungen direkt im BODY-Bereich der Webseite (ohne Funktionsaufruf). Bauen Sie das dritte Beispiel wie folgt um (Name der Datei Plattform2.htm):

<HTML>
<BODY>
<SCRIPT LANGUAGE="JavaScript">
document.write('<HTML>');
document.write('<HEAD>');
document.write('<title>Wer bist Du</title>');
document.write('</HEAD>');
document.write('<BODY>');
document.write('<H1 align=center>Big Brother is watching you</H1>');
document.write('<H4 align=center>');
document.write('Herzlich willkommen ');
document.write('</H4>');
document.write('<H4 align=center>');
document.write('Ich weiss bereits einiges über Sie');
document.write('</H4>');
document.write('<P>Sie verwenden folgenden Browser: ');
document.write(navigator.appCodeName + ', ' + navigator.appName + ', '
  + navigator.appVersion);
document.write('<P>Ihre eingestellte Sprache ist ');
document.write(navigator.language + '.');
document.write('<P>Ihr Betriebssystem ist ');
document.write(navigator.platform + '.');
document.write('</P>');
document.write('</BODY>');
document.write('</HTML>');
</SCRIPT>
</BODY>
</HTML>

Abbildung 2.10:  Das gibt der Internet Explorer 5.01 unter Windows 98 bekannt.

Abbildung 2.11:  Opera 3.6 unter Windows NT 4.0

Abbildung 2.12:  Opera 4 unter Windows 98

Das Beispiel gibt die gleichen Informationen aus wie Beispiel 3, nur funktioniert es auch unter dem Opera Browser. Der gibt sich allerdings als Netscape Browser aus (der Grund ist, dass er weitgehend dazu kompatibel ist) und geizt auch - gerade in den Version vor 4.0 - mit korrekten Informationen.

Client-seitige versus Server-seitige Scripte

Bei Scripten (wie auch vielen anderen Techniken in einem Netzwerk) muss man grundsätzlich den Ort berücksichtigen, wo sie ausgeführt werden. Im Wesentlichen kann man beim Ort zwischen dem Server und dem Client unterscheiden. Was Client-seitige Scripte sind und was man damit machen kann, haben wir ja schon gesehen. Aber was leisten nun Server-seitige Scripte und wozu gibt es sie überhaupt? Dies klarzumachen ist um so wichtiger, da wir uns in dem Buch schwerpunktmässig auf Client-seitige Scripts konzentrieren. Es sollte klar sein, was Server-seitige Scripte zu leisten vermögen, was deren Einsatzgebiete sind und wo die Grenzen von Client-seitigen Scripten liegen.

So elegant die Verlagerung von Funktionalität auf den Client über Client- seitige Scripte ist - es lassen sich nicht sämtliche Funktionalitäten vom Server auf den Client verschieben. Das liegt einmal an der relativen Einfachheit von Scriptsprachen, zum anderen in der Natur der Sache. Wenn man alle Funktionalität beim Client lösen könnte, würde ja keine Server-Client-Logik für den Internet-Prozess benötigt werden. Insbesondere lassen sich mittels Client-seitigen Scripten in der Regel keine Aufgaben lösen, die auf dem Server Aktionen wie Schreiben oder Lesen von Dateien notwendig machen. So etwas ist nahezu immer dann notwendig, wenn mehrere Clients auf einen Server zugreifen und dies irgendwie im Rahmen einer Webseite protokolliert werden soll.

Als Beispiel kann man sich einen Webseitenzähler vorstellen, der überwacht, wie oft eine Webseite auf einem Server aufgerufen wird, ein Gästebuch oder einen Online-Shop mit Datenbank, wo Bestelldaten aufgenommen werden. Solche Informationen müssen zwingend auf dem Server geführt werden, und man muss für Aktivitäten so gut wie immer auf Server-seitige Scripte oder Programme zurückgreifen.

Server-seitige Scripttechnologien sind etwa CGI oder auch Server-seitige JavaScripte. Auch Techniken wie LiveWire (eine Technologie des Netscape-Webservers), ASP (Active Server Pages - eine Technologie für Microsoft-Webserver) oder Java-Servlets (serverseitige Java-Applets, die auf dem Server durch die dortige virtuelle Javamaschine ausgeführt werden) gehören in diese Welt.

Server-seitige Techniken sind auf jeden Fall sehr interessant und leistungsfähig. Sie unterliegen jedoch diversen Einschränkungen, die ihren objektiven Nutzen für viele Privatanwender erheblich reduzieren. Erstes Problem - der Webserver, auf dem sie laufen sollen, muss über einen Interpreter für die Sprache verfügen, mit der das Server-seitige Script erstellt wurde (was natürlich auch auf Clientseite gilt - dort ist jedoch die Bereitstellung eines solchen Interpreters weniger ein Problem, da ihn für eine Sprache wie JavaScript jeder moderne Browser bereitstellt). Dies kann man zwar vielfach bei einer weit verbreiteten Sprache wie etwa Perl voraussetzen, jedoch bei anderen Sprachen ist das oft nicht gegeben. Für die gleiche Funktionalität muss unter Umständen mehr als ein Script geschrieben werden.

Daneben gibt es noch weitere potentielle Probleme. Besonders beschränkend für viele Webseitenersteller erweist sich, dass zahlreiche Provider die Ausführung von Server-seitigen Fremdscripten nicht gestatten. Zwar stellen sie oft eigene Scripte für den allgemeinen Gebrauch bereit. Den Upload (und/oder das Ausführen) von selbst geschriebenen Scripten, die ihren Server steuern sollen, unterbinden sie jedoch meist. Für den Webprogrammierer, der seine Seiten bei einem solchen Provider platzieren möchte (insbesondere zählen dazu auch die großen Provider AOL, T- Online und CompuServe), ist eine Beschäftigung mit dem Erstellen von den teilweise doch recht komplizierten Server-seitigen Prozessen also oft ein wenig frustrierend - die Resultate können nicht in natura verwendet werden.

Die Einrichtung eines eigenen Webservers wie Sambar (ein frei verfügbarer Webserver für Windows - nicht mit Samba4 unter Linux zu verwechseln) als Alternative ist zwar unproblematisch und auch aus verschiedensten Gründen sehr zweckmäßig, dahingegen die Bereitstellung einer permanenten Verbindung zum Internet (geeignete Hardware, eigene feste IP-Nummer, Standleitung, Einrichtung einer zuverlässigen Firewall, etc.) sehr aufwendig und kostenintensiv. Der Webserver wird also meist nur im eigenen Intranet oder sogar nur zusammen mit dem Clientprogramm auf einem einzigen Rechner laufen.

Zusammenfassung

Sie haben an dem heutigen Tag einen ersten Eindruck von JavaScript sowie verwandten oder ergänzenden Technologien wie HTML, VBScript, Java, XML, XSL, Perl oder CGI gewonnen. Insbesondere haben Sie mit einigen Beispielen bereits praktisch JavaScript-Programmierung geübt. Ein Augenmerk galt dem Unterschied zwischen Server-seitigen und Client- seitigen Techniken, wobei insbesondere damit die Möglichkeiten von JavaScript auf Clientseite deutlich gemacht werden sollten, aber auch wo dazu ergänzende Vorgänge auf dem Server unumgänglich werden.

Morgen wollen wir uns um HTML-Grundlagen und vor allem die Einbindung von JavaScripten in Webseiten kümmern.

Fragen und Antworten

Frage:
Es wird im Buch gelegentlich von Scriptsprachen und dann wieder Programmiersprachen gesprochen. Ist das identisch?

Antwort:
Es kommt darauf an, wie diese Begriffe verwendet werden. Wir wollen sie unterschiedlich einsetzen. Scriptsprachen sind solche Sprachen, die im Wesentlichen zur Programmierung einer Umgebung (etwa eines Browsers, aber auch des Betriebssystems wie mit WHS - Windows Host Scripting - unter Windows) verwendet werden. In der Regel erweitern sie die sonst in der Umgebung bereits vorhandenen Möglichkeiten und/oder automatisieren bestimmte Vorgänge, die ein Anwender auch Schritt für Schritt manuell durchführen könnte. Programmiersprachen sind Sprachen, mit denen eigenständige Programme erstellt werden, die nicht nur hauptsächlich ihre Umgebung über eine Schnittstelle beeinflussen können und vor allem keine solche interpretierende Umgebung benötigen. Dazu zählen Sprachen wie Java, C/C++, Delphi, aber auch Visual Basic und sogar Basic selbst. Die Unterscheidung ist irgendwo etwas willkürlich, denn streng genommen benötigen auch in Programmiersprachen erstellte Programme eine Umgebung (zumindest das Betriebssystem oder bei Java die JVM), innerhalb der sie agieren können. Auch die Unterscheidung in compiliert und interpretiert greift nicht, denn Basic-Programme sind interpretiert. Dennoch - das Charakteristikum, vornehmlich die Schnittstelle einer interpretierenden Umgebung steuern und Vorgänge automatisieren zu können, beschreibt eine Scriptsprache recht gut.

Frage:
Sind Client-seitige oder Server-seitige Scripte wichtiger?

Antwort:
Für normale Anwender ohne uneingeschränkten Zugang sicher Client-seitige Scripte. Zumal sie einfacher zu lernen sind. Bei Kontrolle über einen Server kann man dies nicht mehr so pauschal sagen. Es kommt auf die Aufgabenstellung an.

Workshop

Experimentieren Sie mit den in diesem Kapitel besprochenen Beispielen ein wenig herum. Versuchen Sie Teile davon so zu verändern, dass die Scripte noch sinnvoll laufen, aber echte Unterschiede zu den Beispielen sichtbar sind.

Kontrollfragen

Im Anhang »Antworten zu den Kontrollfragen« finden Sie die Antworten zu den jeweils am Ende einer Lektion notierten Fragen.

  1. Ist XML eine Ablösung für HTML?
  2. Welche Version von JavaScript ist auf Serverseite aktuell?
  3. Ist VBScript oder JavaScript weiter verbreitet?
  4. Läuft VBScript im Opera-Browser?
  5. Welchen JavaScript-Standard unterstützt der Opera-Browser 3.6?
  6. Sind Java und JavaScript eng verwandt?
  7. Wofür ist CGI die Abkürzung?
  8. Welche Sprache wird hauptsächlich zur Erzeugung von Server-seitigen Scripten eingesetzt?



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisFeedbackKapitelanfangnächstes Kapitel


1234

© Markt+Technik Verlag, ein Imprint der Pearson Education Deutschland GmbH