Blue Flower

Hier ist ein Auszug aus dem Buch JavaScript - Die universelle Sprache zur Web-Programmierung (Kapitel 2)

JavaScript
Cover vergrößern

Ralph Steyer

JavaScript

Die universelle Sprache zur Web-Programmierung
04/2014 -  474 Seiten. Fester Einband

Buch: € 29,99 inkl. kostenlosem E-Book Buch kaufen ISBN: 978-3-446-43942-9

E-Book (PDF): € 23,99 E-Book kaufen ISBN: 978-3-446-43947-4

 


 

  1. Grundlagen und erste Beispiele

Wir beginnen nun mit der Erstellung von Webseiten und der JavaScript-Programmierung. Dazu möchte ich Ihnen zu Beginn dieses Kapitels direkt ein paar einfache JavaScript-Beispiele vorstellen. Bevor wir uns dann jedoch in die Details einarbeiten und zuerst auf die konkrete Erstellung von Webseiten stürzen, schaffen wir uns in diesem Kapitel ein paar weitere Grundlagen, damit die nachfolgenden Schritte leichter verständlich werden. Es erleichtert viele Folgeschritte, wenn wir bei einigen Fachbegriffen von den gleichen Voraussetzungen ausgehen. Sie lernen in diesem Kapitel etwas über:

  • JavaScript mit ersten kleinen Skripten,
  • das Internet im Allgemeinen,
  • die Idee des Programmierens und die spezielle Situation beim Programmieren im Internet und
  • die Funktion eines Browsers.

1.1         Erste JavaScript-Beispiele

Sie wollen sicher JavaScript möglichst schnell in der Praxis erleben und sehen, was man damit machen kann. Was eignet sich besser als selbst ein paar kleine Beispiele einzugeben und auszuprobieren? Wir springen mit dieser Aufgabe direkt ins kalte Wasser. Dabei kalkuliere ich ein, dass Sie unter Umständen nicht so genau nachvollziehen können, was hier getan wird. Das klärt sich im Laufe des Buchs. Geben Sie nur den Quelltext exakt wie vorgegeben ein (mit Beachtung der Groß- und Kleinschreibung, Klammern, Semikolon, etc.). Wichtig ist hier, dass Sie den Umgang mit einem Editor und der grundsätzlichen Erstellung von Quelltext sowie einem Browser üben und dabei erste Effekte sehen, die auf JavaScript beruhen.

1.1.1      Ein einfaches Mitteilungsfenster

Geben Sie den nachfolgenden Quelltext in einem Editor ein und nennen Sie die Datei kap2_1.html. Nun möchte ich bereits den ersten einfachen Beispielen einen Weg gehen, der bei umfangreicheren Beispielen unabdingbar wird. Wir wollen mit einer Projektstruktur arbeiten, was erst einmal hauptsächlich die Strukturierung in Verzeichnissen bedeutet. Dazu möchte ich Ihnen den Einsatz von einer IDE anhand von Aptana (unserer Referenz-IDE) erklären[1]. Wenn Sie also mit Aptana arbeiten, verwendet diese IDE einen sogenannten Workspace. Das ist ein verwaltetes Verzeichnis, in dem Sie alle Projektverzeichnisse speichern. Innerhalb des Workspace erzeugen Sie in Aptana ein neues Web-Projekt mit Namen kap2 (File -> New -> Web Project).

Wählen Sie die Vorgabevorlage für das Projekt aus und vergeben Sie im folgenden Dialog den Projektnamen. Erzeugen wir in dem Projekt nun eine Datei kap2_1.html. Das geht am besten mit File -> New From Template -> HTML. Für unsere Zwecke genügt dann eine Webseite nach dem HTML4-Standard.

Da Aptana einen eigenen Webserver mitbringt, können Sie das Web-Projekt an einer beliebigen Stelle speichern, solange es unter der Verwaltung von Aptana bekannt ist.

Sie müssen nun natürlich nicht den Workspace von Aptana oder überhaupt die Projektverwaltung von Aptana verwenden, sondern Sie können auch eine andere Basisstruktur wählen. Gerade wenn Sie - wie im letzten Kapitel beschrieben - einen Webserver zur Verfügung haben und diesen verwenden wollen. In dem Fall speichern Sie diese Datei (und auch alle anderen Beispieldateien in diesem Buch) in dem Verzeichnis, das über Ihren Webserver freigegeben ist. Im Fall einer XAMPP-Installation ist dies das Verzeichnis htdocs. Legen Sie dort am besten ein Unterverzeichnis mit Namen kap2 an. Dort hinein soll diese Datei gespeichert werden.

CHV_BOX_ID_02
icn002 HinweisDie Beispieldateien der nächsten Kapitel sollten dementsprechend in analogen Unterverzeichnissen auf dem Webserver oder dem Workspace von Aptana abgelegt werden. Sie können auch den Workspace von Aptana so konfigurieren, dass das htdocs-Verzeichnis von Apache das Workspace-Verzeichnis darstellt.  

Doch kommen wir nun zum Quelltext. Dies soll der Inhalt der Quelltextdatei kap2_1.html sein:

Listing 1.1       Das erste JavaScript-Beispiel

<html>

<body>

<script>

alert("Hallo Welt");

</script>

</body>

</html>

In den Zeilen 3 bis 5 der Webseite finden Sie einen stark vereinfachten Skript-Container und die eigentliche JavaScript-Anweisung steht in der vierten Zeile. Rufen Sie die Datei mit Ihrem Standardbrowser über den Webserver auf. Wenn der Webserver auf den gleichen Rechner läuft wie ihr Webbrowser, würde der Aufruf wie folgt lauten, wenn Sie sich an meine Empfehlung bezüglich der Wahl eines Verzeichnisses gehalten haben:

http://localhost/kap2/kap2_1.html

In Aptana können Sie die Datei auch direkt aus der IDE ausführen. Dazu müssen Sie die Datei bloß selektieren und im Menü den Befehl Run -> Run as... -> JavaScript Web Application aufrufen. Aptana startet dann seinen integrierten Webserver und stellt die Webseite darüber in dem zugeordneten Standardbrowser dar. Alternativ können Sie auch mit dem Kontextmenü arbeiten. Ihr Browser sollte in jedem Fall ein kleines Dialogfenster mit dem Text Hallo Welt anzeigen.

Troubleshooting

Sollte das Beispiel nicht funktionieren, überprüfen Sie zuerst Ihren Quelltext. Achten Sie vor allen Dingen auf Klammern, Hochkommata, Semikolon sowie Groß- und Kleinschreibung.

Stimmt der Quellcode exakt mit der Vorgabe überein und das Beispiel funktioniert dennoch nicht, wird eventuell JavaScript in Ihrem Browser deaktiviert sein. Dann müssen Sie JavaScript in den Einstellungen Ihres Browsers aktivieren. Wo das genau gemacht wird, ist von Browser zu Browser unterschiedlich. Mittelweile ist auch die Tendenz in Browsern zu beobachten, dass Anwender JavaScript gar nicht mehr direkt deaktivieren können. Von daher ist die potentielle Fehlerquelle auch nicht sonderlich wahrscheinlich. Aber eventuell haben Sie auch in Firefox das Add-on NoScript aktiviert. Dann müssen Sie ggf. die Ausführung für das Skript noch erlauben (das kann in der Regel individuell für jede geladene Datei ausgewählt werden - wenn Sie die Ausführung individuell zulassen, schwächen Sie Ihren allgemeinen Schutz des Browsers damit nicht).

Sollte nach Aktivierung der JavaScript-Unterstützung das Beispiel (scheinbar) immer noch nicht funktionieren, kann es daran liegen, dass das Dialogfenster geblockt wird. Auf Grund diverser Sicherheitsprobleme im WWW, verhindern einige (vor Allem neuere) Browser so genannte aktive Inhalte. Sollten Sie eine entsprechende Warnung bekommen, müssen Sie zur Ausführung von dem Beispiel die aktiven Inhalte für dieses Beispiel zulassen

CHV_BOX_ID_04
icn004 HintergrundinformationDer Zugriff über http://localhost wird in der Regel (bei den meisten Browsereinstellungen) als sicher angesehen, der Zugriff über das file-Protokoll hingegen oft nicht. Wenn Sie die Sicherheitseinstellungen Ihres Browsers nicht schwächen wollen, Sie die ständigen Warnmeldungen aber nerven, haben Sie hier ein Argument mehr, warum Sie auch bei einem lokalen Laden einer Webseite den Zugriffsweg über den Webserver wählen sollten.  

1.1.2      Schreiben eines angepassten Aktualisierungsdatums

Spielen wir ein weiteres Beispiel durch, in dem das Aktualisierungsdatum der Webseite dynamisch mit JavaScript geschrieben wird. Geben Sie den nachfolgenden Quelltext in einem Editor ein (wieder ohne die vorangestellten Zahlen):

Listing 1.2       Das zweite JavaScript-Beispiel

<html>

<body>

Die Webseite wurde zuletzt am

<script>

document.write(new Date());

</script>

aktualisiert.

</body>

</html>

Speichern Sie die Datei unter dem Namen kap2_2.html. In den Zeilen 4 bis 6 finden Sie wieder einen Skript-Container und die eigentliche JavaScript-Anweisung steht in der fünften Zeile. Beachten Sie, dass vor dem Skript-Container  als auch danach reiner Text steht, der nicht zum Skript zählt. Hier sind wir noch in der HTML-Welt. Öffnen Sie die Datei in Ihrem Standardbrowser, um zu sehen was der Quellcode bewirkt. Im Anzeigebereich des Browsers sollte ein Text zu sehen sein, der aus den statischen Textpassagen und einer dynamisch per JavaScript generierten Information (dem Tagesdatum mit einer Genauigkeit von dem Bruchteil einer Sekunde) besteht.

1.1.3      Entgegennahme einer Benutzereingabe

Geben Sie für ein abschließendes Einstiegsbeispiel den nachfolgenden Quelltext in einem Editor ein und speichern Sie diesen unter dem Namen kap2_3.html:

Listing 1.3       Entgegennahme einer Benutzereingabe

<html>

<body>

Das ist die Webseite von

<script>

document.write(prompt("Ihr Name"));

</script>

.

</body>

</html>

In den Zeilen 4 bis 6 finden Sie wieder den Skript-Container und die eigentliche JavaScript-Anweisung steht in der fünften Zeile. Auch in diesem Beispiel steht vor dem Skript-Container als auch danach reiner Text, der nicht zum Skript zählt. Beim Öffnen der Datei in einem Browser sollten Sie ein kleines Eingabefenster angezeigt bekommen, in dem Sie Ihren Namen eingeben sollen.

Im Anzeigebereich des Browsers werden Sie nach der Eingabe eines Namens und der Bestätigung des Dialogs einen Text sehen, der aus den statischen Textpassagen und der Eingabe durch den Anwender besteht.


 

1.2         Einige Details zum Internet und dem WWW

Kommen wir zu ein paar Details rund um das Internet und das WWW. Ich gehe wie erwähnt davon aus, dass jeder Leser Erfahrung mit diesem Medium hat. Dennoch sollen einige Details geklärt werden, denn es gibt - trotz der Popularität vom Internet - eine Reihe von Missverständnissen, die einer erfolgreichen Web-Programmierung im Weg sind. Das Internet mit all seinen Diensten gehört als Ganzes niemandem und doch allen Internet-Teilnehmern zugleich. Es gibt zwar einige Organisationen, welche sich mit den unterschiedlichsten Aspekten des Internets beschäftigen. Insbesondere auf Ebene der einzelnen Dienste gibt es Organisationen zur Lenkung verschiedenster Belange. Besonders wichtig in Bezug auf die Web-Programmierung ist das W3C (World Wide Web-Consortium - http://www.w3.org), das für die Standards im WWW und damit auch HTML, Cascading Style Sheets und XML verantwortlich ist. Das W3C ist - wie alle diese Organisationen - jedoch weitestgehend auf die freiwillige Kooperation der Internet-Gemeinde und vor allen Dingen der Browserhersteller angewiesen. Leider aber kann durch den rein empfehlenden Charakter des W3C nicht das Problem gelöst werden, dass Vorgaben vom W3C von Browserherstellern einfach ignoriert oder in einer nichtstandardisierten Weise umgesetzt werden.

1.3         Die Besonderheit bei der Web-Programmierung

Allgemein programmiert man heutzutage in einer so genannten höheren Programmiersprache. Beispiele für solche höheren Programmiersprachen sind Basic, Java, C#, Cobol, Fortran, C/C++, Pascal oder auch JavaScript. Eine höhere Programmiersprache beinhalten einen Satz von Klartextsprachelementen mit festgelegter Bedeutung, die meist der englischen Sprache angelehnt sind und eine zugehörige Syntax. Die in einer höheren Programmiersprache geschriebenen Anweisungen (der Quelltext) sind reiner Klartext, der erst einmal für jeden potentiellen Zielprozessor (weitgehend) identisch sein kann. Eine höhere Programmiersprache ist bedeutend einfacher als Maschinensprache (eine Folge von Nullen und Einsen) zu handhaben, die aber letztendlich jeder Prozessor benötigt. Normalerweise erfolgt also moderne Programmierung, indem ein Programmierer Anweisungen an den Computer in einem einfachen Klartexteditor oder einer darauf aufbauenden integrierten graphischen Entwicklungsumgebung (IDE) eingibt. Bevor aus solchem Quelltext jedoch ein ausführbares Programm wird, muss irgendwann die Übersetzung in die prozessorabhängige Maschinensprache erfolgen.

1.3.1      Kompilierung versus Interpretation

Diese Überführung in Maschinensprache kann entweder direkt dann erfolgen, wenn der Quellcode fertig eingegeben ist. Der gesamte Quellcode wird in einem Arbeitsprozess in Maschinensprache übersetzt und das fertige Produkt an den Anwender weitergegeben. Dieser Prozess heißt Kompilierung und wird von der Entwicklungsumgebung  - je nach eingestellter Option - weitgehend automatisch vollzogen. Dabei muss - je nachdem, auf welchen Prozessor das Programm laufen soll - unter Umständen für jede Plattform ein separates Programm erstellt werden.

Eine alternative Möglichkeit ist, dass der plattformneutrale Quelltext an den Anwender weitergegeben und erst Schritt-für-Schritt zu der Zeit übersetzt wird, wenn das Programm ausgeführt werden soll. In diesem Fall müssen Sie als Programmierer nur den Quelltext erstellen und unverändert weitergeben. Der Anwender lädt den Quelltext in ein passendes Programm und sobald eine Anweisung ausgeführt werden soll, wird sie unmittelbar davor beim Anwender übersetzt. Der Quelltext wird also zur Laufzeit eines Programms interpretiert und das Verfahren nennt sich dementsprechend Interpretation.

Nun hat sich im WWW eine der beiden Möglichkeiten zur Übersetzung des Quellcodes eindeutig durchgesetzt - die Interpretation. Aber warum?

1.3.2      Unterschiedliche Plattformen und Interpretation

Das Internet ist heterogen! Sagt Ihnen dieser Satz etwas? Heterogen? Nach Definition im Lexikon heißt das uneinheitlich, ungleichartig. In unserem Zusammenhang bedeutet dies, dass wir im Internet die unterschiedlichsten Plattformen vorfinden. Großrechner neben APPLE-Computer und PCs sowie mobilen Geräten. Eine Vielzahl von unterschiedlichen Prozessoren tummelt sich im weltweiten Netz. Aber nicht nur das - Großrechnerbetriebssysteme neben PC-Betriebssystemen, UNIX samt Derivaten neben Windows mit seinen vielen Ausprägungen. Auch die Kommunikationswege sind uneinheitlich.

Diese Heterogenität erzwingt eine ganz besondere Technik, auf welche Art und Weise Daten zwischen den Welten ausgetauscht werden müssen. Die Daten müssen für alle Systeme verständlich sein. Auf der einen Seite - dem Transport - übernehmen dies im Internet Protokolle wie TCP/IP, welche eine plattformneutrale Übertragung gewährleisten. Die darauf aufsetzenden Dienstprotokolle wie HTTP oder FTP gewährleisten die plattformneutralen Anwendungsumgebungen. Aber auch auf Seiten der konkreten Anwendung dürfen keine plattformbezogenen Anweisungen verwendet werden, wenn man nicht bewusst gewisse Zielplattformen ausschließen will. Zwar gibt es auch im Internet einige Techniken, die beim Anwender bestimmte Voraussetzungen notwendig machen (etwa nur Windows und den Internet Explorer als Basis oder das Vorhandensein einer herstellerabhängigen Erweiterung) und dann eine weit reichende Funktionalität bieten. Im Internet wurden und werden solche dogmatischen Techniken jedoch kritisch gesehen. Vor Allem werden Anwender ausgeschlossen, die bestimmte Produkte nicht verwenden können oder wollen. Die beste Variante für die Akzeptanz einer Technik in Internet scheint die vollkommene Plattformneutralität zu sein. Das ist auf jeden Fall bei Klartexttechniken gewährleistet, bei denen jede Anweisung auf jeder Plattform verstanden wird. Die Anweisungen werden durch ein spezifisches Programm interpretiert, das auf der jeweiligen Plattform läuft und die neutralen Befehle dann in konkrete Prozessorbefehle übersetzt und diese ausführt. Ich rede also vom Interpreter-Prinzip, das im Web den Königsweg darstellt.

1.3.2.1   Vorteile der Interpretation

Sprachen wie HTML oder JavaScript, aber auch XML sind exzellente Beispiele für so eine Konstellation. HTML als auch JavaScript werden auf jeder Rechnerplattform verstanden. Über einen Interpreter - den Browser - werden die Anweisungen in die jeweiligen Prozessorbefehle übersetzt und ausgeführt (also interpretiert). Interpretation hat noch weitere Vorteile. Die Menge der zu übertragenden Daten ist kleiner, als wenn die gesamte Funktionalität zu übertragen wäre. Außerdem ist es erheblich leichter Änderungen durchzuführen und die gesamte Wartung ist unkomplizierter. Der aufwendige Schritt der erneuten Kompilierung unterbleibt.

1.3.2.2   Nachteile der Interpretation

Die Interpretation bringt nicht nur Vorteile mit sich. Im Vergleich zu einer vollständig in Prozessorbefehle übersetzten Anwendung gibt es einige Nachteile.

Das Laufzeitverhalten von interpretierten Anwendungen ist zum Beispiel nicht gut. Da jeder Befehl erst zur Laufzeit (vollständig) übersetzt wird, wird so eine Anwendung durch die zusätzlichen Schritte langsamer als wenn der Prozessor sich nur mit dem Ausführen der Anweisungen zu beschäftigen hätte. Aber gerade im Fall von JavaScript bringen (fast) alle modernen Browser mittlerweile so genannte "Just-in-Time-Compiler" mit sich. Damit lässt sich dieser Nachteil für moderne RIAs weitgehend aufheben.

CHV_BOX_ID_04
icn004 HintergrundinformationBei der Just-in-time-Kompilierung (JIT-Kompilierung) wird der Quellcode zwar auch erst zur Laufzeit und bei der ersten Verwendung in Maschinencode übersetzt. Dieser native Code kann aber dynamisch optimiert und schneller verarbeitet werden als wenn der Quellcode zeilenweise interpretiert wird. Und der native Code kann im Speicher gehalten werden, was bei einer erneuten Verwendung erhebliche Vorteile bringt.  

Ein weiterer Nachteil ist es unter gewissen Umständen, dass die Befehle und Anweisungen recht leicht durch einen Anwender zu lesen sind (wenn er sich mit der verwendeten Sprache auskennt). Da Interpreter-Code in diesem Fall einfach eine Textdatei ist, ist dieser Quellcode kaum zu schützen, wenn ein Anwender Zugang dazu hat. Nicht jeder Programmierer möchte, dass seine ausgefeilten Befehlsstrukturen so leicht zu analysieren sind.

Ein großes Problem ist, dass Interpretation immer einen erheblichen Spielraum lässt, wie eine Anweisung zu verstehen ist. Insbesondere dann, wenn es sich nur um eine Beschreibungsanweisung handelt, aber grundsätzlich gilt das Problem auch für Skriptsprachen. An Hand von HTML lässt sich das Problem aber leichter verdeutlichen.

Es gibt in HTML beispielsweise eine Anweisung, dass der Anweisung folgender Text hervorgehoben dargestellt werden soll (<strong>), bis die Anweisung wieder aufgehoben wird (</strong>). Der Browser des Anwenders lädt nun eine solche Seite und kommt an den entsprechenden Befehl. Er interpretiert die Anweisung und führt sie aus. Soweit, so gut. Aber wer legt fest, was hervorgehoben eigentlich bedeutet? Neigung der Schrift. Oder fett darstellen? Oder unterstreichen? Jede der Varianten wäre denkbar. Der Hersteller des Browsers A hat sich für die eine Variante entschieden, während der Hersteller des Browsers B eine andere vorzieht. Beide Browser werden also die Anweisung verstehen und durchführen, das Resultat aber bei beiden unterschiedlich aussehen. Diesen Interpretationsspielraum werden Sie bei den unterschiedlichsten Anweisungen in HTML finden und teilweise auch in anderen Techniken wie Style Sheets oder JavaScript. Zwar haben sich die Hersteller von verschiedenen Browsern bei vielen Anweisungen weitgehend geeinigt. Es gibt jedoch immer noch Situationen, die von verschiedenen Browsern ganz unterschiedlich ausgelegt werden. Gerade bei neuen Befehlen dauert es lange Zeit, bis sich die verschiedenen Lager der Browserhersteller einigermaßen geeinigt haben[2]. Ein wichtiger Aspekt darf dabei auch nicht übersehen werden - Browser lassen sich individuell konfigurieren. Das betrifft Standardschriftarten, -größen, -stile, Farben usw. Auch dies führt dazu, dass es bei Interpretation zahlreiche Darstellungen einer Seite geben kann.

Ein großes Problem beim Interpreter-Konzept ist das Veralten der Interpreter. Wenn eine Interpreter-Sprache einen neuen Befehl hinzugefügt bekommt, können die bis dahin entwickelten Interpreter diesen Befehl noch nicht kennen und ihn entsprechend nicht ausführen. Anwender mit solchen Interpretern können unter Umständen ein Programm nicht laufen oder ein Dokument nicht darstellen lassen.



[1] Das soll Sie nicht daran hindern, dass Sie Alternativen wie das Visual Studio oder nur einen einfachen Editor einsetzen, wenn Sie sich damit auskennen oder Ihnen diese Programme genehmer sind.

[2] Ganz massiv sehen wir das im Moment bei HTML5 - konkret bei den neuen Formularelementen.