HTML-Einführung von Hubert Partl


Interaktion mit dem Benutzer

Mehr Leben ins World Wide Web!

Hier finden Sie nur kurze Hinweise auf diese Möglichkeiten für "Fortgeschrittene". Genauere Informationen müssen Sie der Dokumentation des jeweiligen WWW-Servers und den Referenzen entnehmen.


Aktionen am Server (CGI, SSI, ASP, PHP)

CGI (Common Gateway Interface) ist die im Protokoll HTTP vorgesehene Schnittstelle zu Programmen, die am Web-Server installiert sind. Ein CGI-Programm oder eine CGI-Prozedur ist ein Computer-Programm, das auf dem WWW-Server läuft und die Ausgabe wie ein HTML-File an den Client sendet.

Im Gegensatz zu HTML-Files, die einen fixen Inhalt haben, kann man damit Informationen verteilen, die sich laufend ändern oder die von Benutzer-Eingaben abhängen.

Der Aufruf der CGI-Prozedur erfolgt in einem Hypertext-Link oder einem Formular mit einem URL der Form
http://hostname/cgi-directory/filename
oder
http://hostname/cgi-directory/filename?parameterliste

Beispiel:

- - - Eine einfache Unix-Shell-Prozedur wie

#!/bin/sh
echo "Content-Type: text/html"
echo ""
echo "<html><head><title>Datum</title></head>"
echo "<body><p>Today is "
/bin/date
echo "</body></html>"
exit
- - - sendet z.B. den folgenden HTML-Code an den Client
<html><head><title>Datum</title></head>
<body><p>Today is
Thu Mar 8 19:30:00 MET 2001
</body></html>
- - - und das bewirkt eine Darstellung wie

Today is Thu Mar 8 19:30:00 MET 2001

- - -

Eine etwas ausführlichere Version einer solchen Datumsanzeige finden Sie an der BOKU Wien.

CGI-Programme und Prozeduren können in beliebigen Sprachen geschrieben werden (Shell-Scripts, Perl-Scripts, C-Programme, Java-Programme u.a.). Die Detail-Informationen dazu finden Sie in der Dokumentation des jeweiligen WWW-Servers und in den Referenzen, siehe auch die Hinweise von Stefan Münz zu CGI-Programmen und Perl.

Wenn das CGI-Programm in Java geschrieben wird und wenn der Web-Server es unterstützt, dann kann man dieses Java-Programm als sogenanntes Java-Servlet einrichten, das dann besonders effizient innerhalb des Web-Servers läuft. Mehr darüber finden Sie in der Java-Einführung und in den dort angeführten Referenzen.

Andere Möglichkeiten, nicht ein fixes HTML-File sondern eine zur Aufrufzeit dynamisch generierte bzw. modifzierte HTML-Seite auszugeben, sind

Ob und wie das funktioniert, hängt von der verwendeten Web-Server-Software ab und ist in deren Dokumentation beschrieben.

Beispiel

Hier ein Beispiel für ein PHP-File, das eine Datenbank-Abfrage in einen HTML-Text einbettet:

- - - Das PHP-File am Server

<html>
<head>
<title>freie Plaetze</title>
</head>
<body>
<p>
Im <b>HTML-Kurs</b> sind noch

<?php
  $con = ocilogon ('KursDB', 'user', 'password');
  $sql = "SELECT frei FROM kurse WHERE titel='HTML-Kurs' " ;
  $stmt = ociparse ($con, $sql);
  ociexecute ($stmt);
  while ( ocifetch ($stmt) ) {
    $frei = ociresult ($stmt, 'frei');
    print($frei);
  }
  ocilogoff ($con);
?>

Pl&auml;tze frei.
</body>
</html>
- - - sendet z.B. den folgenden HTML-Code an den Client
<html>
<head>
<title>freie Plaetze</title>
</head>
<body>
<p>
Im <b>HTML-Kurs</b> sind noch
3
Pl&auml;tze frei.
</body>
</html>
- - - und das bewirkt eine Darstellung wie

Im HTML-Kurs sind noch 3 Plätze frei.

- - -

Für vollständige Informationen über PHP wird auf die Referenzen verwiesen.


Zugriffe zählen

Sie als Autor möchten wahrscheinlich wissen, wie oft Ihre Informationen von Interessenten in aller Welt gelesen werden.

Relativ leicht können Sie erfahren, wie oft auf Ihr HTML-File am WWW-Server zugegriffen wurde. Die meisten WWW-Server führen ein "Log-File", in dem alle Zugriffe protokolliert werden, und Sie können mit einem einfachen Unix-Shell-Script zählen, wie oft Ihr Filename darin vorkommt. Beispiel:

#!/bin/sh
url="$1"
logfile=/usr/local/apache/logs/access_log
n=`grep -i "$url" $logfile | wc -l`
echo "$n Zugriffe auf $url"
exit
Außerdem finden Sie im Log-File auch die Information, von welchen Client-Rechnern auf Ihr File zugegriffen wurde (aber im allgemeinen nicht, von welchen Personen).

Damit zählen Sie aber nur die Anzahl der File-Übertragungen und nicht, wie oft die Information tatsächlich gelesen wurde. Schuld daran sind die sehr nützlichen sogenannten Cache-Speicher, die zur Entlastung der Netzverbindungen notwendig sind:

Die meisten Web-Browser haben einen lokalen Cache-Speicher. Wenn z.B. ein Benutzer in Berlin zehn mal die in Wien gespeicherte HTML-Einführung liest, wird sie nur beim ersten Mal von Wien nach Berlin übertragen und, solange der Platz ausreicht, in seinem Cache-Speicher abgelegt. Bei allen weiteren Zugriffen wird das File nicht nochmals von Wien nach Berlin übertragen, sondern viel einfacher und schneller aus dem lokalen Cache geholt (außer der File-Inhalt wurde inzwischen erneuert).

Viele Institutionen verwenden auch globale Cache-Server ("Proxy"), die dann für alle Zugriffe aus diesem Bereich wirken. Wenn z.B. tausend Benutzer in Berlin die in Wien gespeicherte HTML-Einführung lesen, wird sie nur beim ersten Mal von Wien nach Berlin übertragen und eine Kopie am Berliner Cache-Server abgelegt (solange der Speicherplatz ausreicht). Bei allen weiteren Zugriffen wird das File nicht nochmals von Wien nach Berlin übertragen, sondern viel schneller aus dem Berliner Cache-Server geholt (außer der File-Inhalt wurde inzwischen erneuert).

Die Zahl, wie oft Ihr File tatsächlich gelesen wurde, ist im allgemeinen also wesentlich höher als die am WWW-Server gezählte Zahl der File-Übertragungen.

Manche Autoren wollen die Zahl der Zugriffe auch innerhalb des HTML-Files speichern. Dies ist zwar technisch möglich (z.B. mit Hilfe einer CGI-Prozedur), aber nicht empfehlenswert, weil das eine zusätzliche Netz- und Server-Belastung bedeutet und weil die Anzahl der File-Übertragungen meist ohnehin nur für den Autor der Information und den Verwalter des WWW-Servers, aber nicht für die Leser interessant ist.


Formulare <form>

Der Inhalt von HTML-Files wird jeweils vom WWW-Server zum Benutzer am Client gesendet. Mit Hilfe von Formularen, die in HTML-Files stehen, können in der Gegenrichtung die Benutzer bestimmte Informationen am Client eingeben und an den WWW-Server senden. Diese Daten werden meistens von einer auf diesem Server laufenden CGI-Prozedur verarbeitet.

Beispiel:

- - - Die Eingabe von

<form method="get"
action="http://www.boku.ac.at/cgi-bin/hein-get">
<b>Anmeldung</b> zur Geburtstagsfeier am 8. M&auml;rz
<p>
<input type="radio" name="kommt" value="ja" checked>
Ich komme.
<br>
<input type="radio" name="kommt" value="nein">
Ich komme nicht.
<p>
Name:
<input name="wer" size="40" maxlength="512">
<p>
Telefonnummer:
<input name="tel" size="20" maxlength="512">
<p>
<input type="submit" value="Anmeldung absenden">
</form>
- - - bewirkt eine Darstellung wie

Anmeldung zur Geburtstagsfeier am 8. März

Ich komme.
Ich komme nicht.

Name:

Telefonnummer:

- - -

Anmerkung: Die in diesem Beispiel verwendete CGI-Prozedur dient nur für Tests durch die Leser dieser Einführung. Wenn Sie dieses Formular ausfüllen und absenden, bekommen Sie eine kurze Test-Antwort, aber (leider) keine wirkliche Einladung zum "Heurigen".

Eine "echte" Anmeldungs-Prozedur würde die Zu- und Absagen mit Name und Telefonnummer in einer Datenbank speichern und dann die Bestätigung an den Client senden.

Das Senden einer solchen Antwort ist immer notwendig, denn der Benutzer muss auf seinem Bildschirm erkennen können, dass das "Anklicken" des Submit-Knopfes funktioniert hat ("Feedback"). Im einfachsten Fall genügt eine kurze Meldung, dass die Eingabe verarbeitet wird, und eventuell ein Hinweis, dass der Benutzer mit der Back-Taste oder dem Back-Befehl seines Browsers zur vorherigen Information zurückkehren und weiterarbeiten kann.

Bei der Gestaltung von Formularen müssen die Normen und Konventionen für Benutzerschnittstellen und die Gewohnheiten und Erwartungen der Benutzer berücksichtigt werden.

Für genauere Informationen über die vom Server unterstützten Übertragungs-Methoden ("get" oder "post") und die Übergabe der Eingabedaten an die CGI-Prozedur wird auf die Dokumentation des jeweiligen WWW-Servers und auf die Referenzen verwiesen. Die CGI-Prozeduren müssen so geschrieben werden, dass Ihre Ausführung kein Sicherheitsrisiko für den Server-Computer darstellen kann, egal was für eventuell seltsame Eingaben von den Benutzern kommen.

Wenn Sie keine Möglichkeit haben, ein CGI-Programm auf dem von Ihnen verwendeten WWW-Server zu installieren, bietet sich als Alternative die Verwendung von Electronic Mail an.

Manche (wenige) Web-Browser bieten die Möglichkeit, Formulare per E-Mail zu verarbeiten. Dazu würden Sie im Formular mit
<form action="mailto:user@host.domain" enctype="text/plain">
Ihre eigene Mail-Adresse angeben, und jedesmal, wenn ein Leser dann den Submit-Knopf "drückt", bekommen Sie den Formularinhalt als lesbaren Text per E-Mail in Ihre Mailbox gesendet und können ihn dann händisch oder mit einem auf Ihrem Computer laufenden Programm verarbeiten.

Allerdings werden solche Mailto-Formulare von sehr vielen Web-Browsern nicht unterstützt. Diese Methode kann daher nur innerhalb von kleinen, geschlossenen Benutzergruppen eingesetzt werden, bei denen man sicher ist, dass sie alle eine dafür geeignete Browser-Version verwenden, abe nicht für allgemein verwendbare Anwendungen.

Deshalb sollte man, wenn man keine CGI-Programme verwenden kann, lieber gar keine Formulare verwenden sondern ein normales Mailto-Link, bei dem die Benutzer den Text "formlos" schreiben und per E-Mail absenden können. Diese Möglichkeit steht dann allen Internet-Benutzern offen.

Beispiel:

<p>
Bitte senden Sie Ihre Anmeldung per
<a href="mailto:user@host.domain">E-Mail
an user@host.domain</a>
oder per Telefax an ...

- - -


Image-Maps (ismap <map> usemap)

Image-Maps (Bild-Karten) erlauben die Verzweigung zu bestimmten Informationen durch die Auswahl ("Anklicken") von bestimmten Regionen innerhalb eines Inline-Bildes.

Dafür gibt es zwei verschiedene Verfahren:

In HTML 4 wird empfohlen, in Zukunft nur mehr Client-seitige und nicht mehr Server-seitige Image-Maps in HTML-Files einzubauen.

Server-seitige Image-Maps (ismap)

Bei Server-seitigen Image-Maps muss die Verarbeitung durch eine auf dem WWW-Server laufende CGI-Prozedur erfolgen. Diese Möglichkeit war bereits in HTML 2 vorgesehen und wird von allen graphikfähigen Web-Browsern unterstützt.

Im HTML-File ist eine Kombination aus einem <a href>-Befehl für die CGI-Prozedur und einem <img>-Befehl für das Bild mit der Angabe "ismap" anzugeben.

Beispiel:

- - - Die Eingabe von

<a href="http://www.boku.ac.at/cgi-bin/hein-map">
<img src="austria.gif" ismap></a>
- - - bewirkt eine Darstellung wie

und je nachdem, wo in diesem Bild Sie "klicken", bekommen Sie eine entsprechende Antwort von der CGI-Prozedur.

- - -

Für genauere Informationen über das Zusammenspiel zwischen Bild und CGI-Prozedur und über Hilfsprogramme zu deren Erstellung wird auf die Referenzen verwiesen.

Client-seitige Image-Maps <map> usemap

Bei Client-seitigen Image-Maps erfolgt die Verarbeitung durch den Web-Browser auf Grund von entsprechenden Angaben im HTML-File, und es ist keine CGI-Prozedur notwendig. Diese Möglichkeit ist seit HTML 3.2 vorgesehen und wird von allen neueren Web-Browsern unterstützt.

Die Spezifikation, welche Teile des Bildes den Sprung zu welchem Hypertext-Link bewirken sollen, erfolgt mit Hilfe von <map> entweder im selben HTML-File wie die Verwendung des Bildes oder in einem separaten File, das gemeinsam mit dem Bild abgespeichert ist.

Im <img> oder <object>-Befehl des Bildes wird dann mit "usemap" auf diese Map-Spezifikation verwiesen.

Da nicht alle Benutzer die Darstellung von Bildern eingeschaltet haben und da manche Web-Browser und viele Suchmaschinen solche Image-Maps nicht richtig verarbeiten, muss man bei einer Image-Map zusätzlich ein "normales" Link mit <a href> angeben, das zu einer Liste von Hypertext-Links in einfacher Textform führt. Damit wird sichergestellt, dass alle Benutzer und Suchhilfen die betreffenden Informationen erreichen können.

Beispiel:

- - - Die Eingabe von

<map name="map3">
<area shape=rect coords="0,0,89,15"  href="#oben"  alt="oben">
<area shape=rect coords="0,16,89,31" href="#mitte" alt="mitte">
<area shape=rect coords="0,32,89,47" href="#unten" alt="unten">
</map>
<p>Klicken Sie auf eines der drei Felder der Fahne
<a href="#ohnemap">
<img src="austria.gif" alt="oder hier!" usemap="#map3"></a>
- - - bewirkt die Ausgabe von

oben mitte unten

Klicken Sie auf eines der drei Felder der Fahne oder hier!

Je nachdem, wo Sie in diesem Bild "klicken", gelangen Sie zu einer der folgenden vier Stellen:

  1. Sie haben das obere rote Feld ausgewählt.
  2. Sie haben das mittlere weiße Feld ausgewählt.
  3. Sie haben das untere rote Feld ausgewählt.
  4. Ihr Browser unterstützt Client-seitige Image-Maps nicht. Sie sind deshalb hier bei der Alternative "ohne Map" gelandet und können die drei Möglichkeiten nun mit normalen Hypertext-Links auswählen:

Die Eingabe für die im vierten Punkt beschriebene Alternative hat einen Aufbau der folgenden Form:

<a name="ohnemap">Ihr Browser ... </a>
Sie ... k&ouml;nnen ... nun ... ausw&auml;hlen:
<ul>
<li><a href="#oben">Informationen zum oberen Bereich</a>
<li><a href="#mitte">Informationen zum mittleren Bereich</a>
<li><a href="#unten">Informationen zum unteren Bereich</a>
</ul>
- - -

Manche Web-Browser stellen <map> nicht als Bild sondern als eine Art Pull-down-Menü mit den in den ALT-Parametern angegebenen Texten dar. Die Angabe dieser Texte mit alt= in <area> ist deshalb zwingend vorgeschrieben.


Aktionen am Client (Java, JavaScript, Active-X, DHTML, XSL)

Im Gegensatz zu CGI-Programmen und Datenbanksystemen, die am Server laufen, gibt es auch Möglichkeiten, Berechnungen oder sonstige Aktionen direkt am Client ablaufen zu lassen, was in vielen Fällen effizienter ist. Allerdings sind dabei Sicherungsmechanismen notwendig, damit nicht irgendwelche fremde Personen oder Hacker Web-Pages so schreiben können, dass auf dem Client-Rechner (PC) des Lesers irgendwelche Aktionen ausgeführt werden, die der Leser gar nicht will.

Viele Benutzer haben wegen dieser Sicherheitsrisiken die Möglichkeiten von JavaScript und dergleichen in ihren Web-Browsern ausgeschaltet. Deswegen und weil diese Möglichkeiten nicht in allen Web-Browsern richtig funktionieren auch von Suchmaschinen nicht unterstützt werden, muss der Autor der Web-Page immer auch Alternativen in gewöhnlichem HTML vorsehen (mit <noscript> etc.).

Die wichtigsten Möglichkeiten sind:


Java-Applets <applet> <param> <object>

Was ist Java?

Java ist eine Programmiersprache, ähnlich wie Pascal, Modula, C und C++.

Java ist plattformunabhängig. Wenn Sie ein Java-Programm auf einem Computer schreiben und kompilieren, dann läuft es unverändert auf allen Arten von Computern, egal ob Windows-PC, Macintosh, Unix-Rechner oder TV-Settopbox.

Java is objektorientiert und eignet sich daher auch sehr gut für komplexe Anwendungen, die aus vielen Einzelteilen bestehen, sowie für graphische User-Interfaces.

Java hat eine umfangreiche Klassenbibliothek, in der Sie viele Klassen für die verschiedensten Zwecke schon fertig vorfinden und damit auch komplizierte Aufgaben mit wenig Aufwand realisieren können (z.B. Bildbearbeitung, dynamisch wachsende Listen, Sortieren, Multithreading, E-Mail, Socket-Verbindungen über das Internet, Datenbankoperationen u.v.a.).

Java hat zahlreiche Sicherheitsmechanismen eingebaut, die vor typischen Programmfehlern schützen. So können Java-Programme zum Beispiel keine "allgemeine Schutzverletzung" bewirken, weil es die Sprachelemente, die dazu führen können (Pointer-Arithmetik u.a.), in Java gar nicht gibt.

Aus allen diesen Gründen eignet sich Java nicht nur für "normale" Computer-Programme sondern auch besonders gut für Anwendungen, die über das Internet verbreitet werden. Neben normalen Java-Applikationen gibt es daher auch Java-Applets, die in Web-Pages eingebaut werden und dann bei jedem Benutzer innerhalb des Web-Browsers ablaufen.

Durch spezielle Sicherheitsvorkehrungen ist sichergestellt, dass diese Applets in den Web-Browser "eingesperrt" bleiben und keine bösen Nebenwirkungen auf den Rechner des Benutzers haben können: Applets können z.B. nicht auf die dort gespeicherten Dateien zugreifen und keine Systemfunktionen oder anderen Programme aufrufen.

Java ist eine neue und moderne Programmiersprache. Dieser Vorteil ist gleichzeitig auch ein Nachteil: Java ist so neu, dass seine Eigenschaften noch laufend erweitert und verbessert werden. Seit 1995 gibt es Version 1.0, Anfang 1997 kam Version 1.1 heraus, Ende 1998 die Version 1.2 (auch Java 2 genannt). Die Hersteller der Web-Browser haben Mühe, mit dieser Entwicklung Schritt zu halten. Dies sollte sich aber in hoffentlich nicht zu ferner Zukunft bessern.

Ich bin davon überzeugt, dass Java in ein bis zwei Jahren die nötige Reife und Stabilität erreichen wird und nicht nur eine aufregende Gegenwart sondern auch eine gute und stabile Zukunft hat.

Java-Applets in HTML

Innerhalb der Web-Page werden Applets mit dem HTML-Tag <applet> eingefügt und aufgerufen. Dies erfolgt nach dem folgenden Schema:

<applet code="Xxxx.class" width=nnn height=nnn>
<param name="xxx" value="yyy">
... Text ...
</applet>

Im Applet-Tag muss mit dem Parameter code der Name des Java-Applet angegeben werden (Class-File mit dem plattformunabhängigen Bytecode), und mit width und height die Breite und Höhe des Applet in Pixels.

In diesem Fall muss sich das Class-File im selben Directory am selben Server wie das HTML-File befinden. Wenn dies nicht der Fall ist, muss man mit einem zusätzlichen Parameter codebase den URL des Directory angeben, aus dem das Class-File geladen werden soll. Beispiel:

<applet codebase="http://www.boku.ac.at/javaeinf/"
        code="HelloApp.class" width=300 height=100>

Falls das Class-File kein einzelnes Files ist sondern in einem komprimierten Archiv (ZIP- oder JAR-File) enthalten ist, ist der Name dieses Archiv-Files mit dem Parameter archive anzugeben:

<applet codebase="http://hostname/dirname/"
        archive="xxxxx.jar" code="Xxxxx.class"
        width=300 height=100>

Mit einem oder mehreren Param-Tags können Parameter an das Applet übergeben werden.

Der (abgesehen von den Param-Tags) zwischen <applet> und </applet> stehende Text wird von den Browser-Versionen, die Java nicht unterstützen, an Stelle des Java-Applet dargestellt. Dies kann beliebig formatierter HTML-Text sein, also z.B. auch Bilder enthalten.

In der neuen HTML-Norm HTML 4.0 ist vorgesehen, dass statt dem Tag <applet> der Tag <object> verwendet werden soll. Dies wird aber von dem meisten Browsern noch nicht unterstützt.

Online-Informationen über Java

Ausführlichere Informationen über Java finden Sie in der Java-Einführung und in den dort angeführten Referenzen sowie in der Newsgruppe de.comp.lang.java

Beispiel: Lake-Applet

Hier ein Beispiel, wie Sie ein fertiges Java-Applet in Ihre Web-Page einbauen und mit <param>-Tags an Ihre Bedürfnisse anpassen können, das - inzwischen schon allzu populäre - Lake-Applet von David Griffiths. Dieses Applet stellt ein Bild als Spiegelung in einem See dar. Das Class-File muss zu diesem Zweck in dasselbe Directory kopiert werden, wo sich auch Ihr HTML-File und Ihr Bild befindet, und mit den Parametern image und href wird angegeben, welches Bild sich im See spiegeln soll und was passieren soll, wenn der User auf das Bild klickt.

Das HTML-File sieht so aus:

<html>
<head>
<title>Badende Venus</title>
</head>
<body>
<h1 align=center>Lake Applet</h1>
<p align=center>
<applet code="lake.class" width=604 height=723>
<param name=image value="http://www.boku.ac.at/htmleinf/big.jpg">
<param name=href value="http://www.boku.ac.at/htmleinf/hein53.html#java">
  Ohne Java k&ouml;nnen Sie das Bild nur
  ohne Wasserspiegelung sehen:
  <p align=center>
  <img src="big.jpg" alt="Badende Venus">
</applet>
</body>
</html>
Wenn Ihr Web-Browser Java unterstützt, dann können Sie hier ausprobieren, wie das aussieht.


JavaScript, <script> <noscript>

Was ist JavaScript?

JavaScript ist etwas anderes als Java.

JavaScript ist keine selbständige Programmiersprache, sondern eine Erweiterung von HTML durch ein paar Script-Befehle, die dann vom Web-Browser ausgeführt werden.

JavaScript ist nicht plattformunabhängig, sondern läuft nur in Netscape und Internet Explorer, und auch da nicht in allen Versionen in der gleichen Weise.

JavaScript verfügt nicht über die guten Sicherheitsvorkehrungen von Java und kann daher durchaus böse Nebenwirkungen auf den Benutzer haben. In noch stärkerem Maße gilt dies übrigens für Active-X und Active Desktop im Internet Explorer und in Windows 98.

JavaScript in HTML

JavaScript wird mit dem HTML-Tag <script> direkt in das HTML-File eingebettet:

<script>
... JavaScript-Programm ...
</script>
<noscript>
... Text ...
</noscript>
Im <noscript>-Block wird in normaler HTML-Schreibweise die Information angegeben, die in der Web-Page erscheinen soll, falls der Benutzer JavaScript ausgeschaltet hat oder falls der Web-Browser oder die Suchmaschine JavaScript nicht unterstützt.

Wenn das JavaScript zum Beispiel dazu dient, Hilfstexte ("Tooltips") anzuzeigen, wenn die Maus an eine bestimmte Stelle zeigt, dann sollen dieselben Erklärungen im <noscript>-Block als normale HTML-Texte stehen. Oder wenn das JavaScript dazu dient, auf andere Web-Pages zu verzweigen, müssen im <noscript>-Block die gleichen Links als normale <a href>-Befehle erscheinen. Dies ist sowohl für Anwender als auch für Suchmaschinen wichtig, die sonst die Informationen in den Links gar nicht erreichen können.

Online-Informationen über JavaScript

Ausführlichere Informationen über JavaScript finden Sie vor allem bei Stefan Münz sowie in der Newsgruppe de.comp.lang.javascript

Soll ich Java oder JavaScript verwenden?

Wenn Sie nur ein paar Spezialeffekte in Ihre Web-Page einbauen wollen - z.B. dass sich ein Link ändert, wenn die Maus darüber fährt, oder dass die Dateneingabe in einem Formularfeld kontrolliert wird, - dann genügt JavaScript.

Wenn Sie in Ihrer Web-Page eine komfortable Benutzerführung oder Berechnungen oder Simulationen ablaufen lassen wollen, dann brauchen Sie Java. Java eignet sich außerdem nicht nur für Applets und Servlets sondern auch für eigenständige Anwendungen (Applikationen) als eine modernere und bequemere Alternative zu anderen Programmiersprachen wie Cobol, Fortran, Basic und C.


Paßwort-Schutz und Sicherheit (SSL, https)

Wenn man den Zugriff auf bestimmte Web-Pages auf bestimmte Personen oder Personengruppen einschränken will, dann soll man die dafür im Web-Server vorgesehenen Funktionen verwenden. Alle Web-Server-Produkte erlauben es, den Zugriff auf Client-Rechner einer Domain (also z.B. nur für alle Benutzer innerhalb des Intranet der Firma oder Universität) zu beschränken oder den Zugriff von der Eingabe eines Username und Paßworts abhängig zu machen, also nur für bestimmte Personen verfügbar zu machen (z.B. nur für zahlende Kunden).

Solche Einschränkungen und Paßwort-Kontrollen dürfen grundsätzlich nur am Server erfolgen. Wenn man versucht, Einschränkungen oder Paßwort-Kontrollen mit Applets oder JavaScript am Client durchzuführen, können erfahrene Benutzer den Inhalt der Applets bzw. Scripts ansehen und den darin enthaltenen Schutz einfach umgehen. Man darf, bildlich gesprochen, niemals Schloß und Schlüssel gleichzeitig aus der Hand geben. Ein sicherer Schutz ist nur auf dem Server möglich.

Die von der Web-Server-Software und dem Protokoll HTTP unterstützte Paßwort-Abfrage hat außerdem den Vorteil, dass das vom Benutzer im Web-Browser eingegebene Paßwort verschlüsselt vom Client an den Server übertragen wird und daher gegen Ausspähen geschützt ist.

Falls andere wichtige oder sensible Daten zwischen Client und Server übertragen werdem (z.B. nach Eintragen im einem Formular an das CGI-Programm), dann muss diese Übertragung verschlüsselt erfolgen. Zu diesem Zweck müssen sowohl der Web-Server als auch der Browser die automatische Verschlüsselung der Daten unterstützen. Dazu werden eine Internet-Verbindung mit SSL (secure socket layer) und das Protkoll https (secure HTTP) verwendet.


Dynamische Web-Pages und Datenbanken

Die meisten Firmen, Universitäten und Institutionen verwenden Workflow-Systeme oder Datenbanken für die Verwaltung von umfangreichen Informationen und Daten. Deshalb ist es in den letzten Jahren immer wichtiger geworden, über das World-Wide Web nicht bloß einzelne Dokumente verfügbar zu machen, die in Form von eigenständigen HTML-Files erstellt und mühsam laufend aktualisiert werden müssen, sondern einen möglichst direkten Zugriff auf die jederzeit aktuellen Informationen und Daten in den Workflow-Systemen und Datenbanken zu ermöglichen.

Dies wird als "dynamische Web-Pages" bezeichnet und über Schnittstellen zwischen dem Web-Server und dem Workflow-System bzw. der Datenbank realisiert, oder über integrierte Server-Systeme, bei denen das Workflow-System bzw. das Datenbanksystem direkt von den Web-Browsern über das Protokoll HTTP bzw. die CGI-Schnittstelle angesprochen werden kann und das System die Ergebnisse im Format HTML an den Web-Browser ausgibt. Beispiele dafür sind z.B. der im Workflow-System Lotus Notes integrierte Domino-Server oder der im Datenbanksystem Oracle integrierte Web-Server.


Electronic Mail (mailto)

Die Angabe eines mailto-URL in einem <a href>-Befehl gibt dem Leser die Möglichkeit, von seinem Client aus eine kurze Nachricht per E-Mail an eine bestimmte Mail-Adresse zu senden, z.B. an den Autor der Web-Page.

Der Benutzer muss das Subject, den Text der Nachricht und seine Absender-Adresse am Client eintippen, und er muss die Erlaubnis zum Absenden von Mail haben.

In HTML 4.0 ist vorgesehen, dass man das "Subject" (den Betreff) in der Form
<a href="mailto:mailadresse" title="subject">...</a>
angeben kann. Dies wird allerdings derzeit noch von vielen Web-Browsern ignoriert, d.h. die E-Mail wird von denen zwar richtig zugestellt, aber eventuell nicht mit dem angegebenen Subject.

Es gibt ein paar Web-Browser, die stattdessen die nicht genormte Form
<a href="mailto:mailadresse?subject">...</a>
unterstützen. Diese Form sollte man aber niemals verwenden, denn sie führt bei allen anderen Web-Browsern dazu, dass die E-Mail überhaupt nicht zugestellt werden kann, weil sie eine durch das "Anhängsel" ungültige Mail-Adresse aufweist.

Ob das Absenden von E-Mail innerhalb des Web-Browsers funktioniert, hängt von der Konfiguration am Client-Rechner ab. Außerdem sind "richtige" Mail-Programme für das Versenden von Electronic Mail im allgemeinen besser geeignet, insbesondere für wichtige oder längere Mail-Texte und für das Lesen von Antworten.

Deshalb und auch für den Fall, dass der Benutzer die Web-Page auf einem Drucker ausdruckt, sollte man die Mail-Adresse nicht nur "versteckt" im URL sondern auch sichtbar im Text angeben.

Beispiel:

- - - Die Eingabe von

Wenn Ihnen meine HTML-Einf&uuml;hrung gef&auml;llt,
sagen Sie es bitte Ihren Kollegen. <br>
Wenn Sie darin Fehler finden, sagen Sie es bitte
<a href="mailto:partl@mail.boku.ac.at">mir</a>.
<br>
Meine Mail-Adresse ist
<a href="mailto:partl@mail.boku.ac.at">partl@mail.boku.ac.at</a>.
- - - bewirkt eine Darstellung wie

Wenn Ihnen meine HTML-Einführung gefällt, sagen Sie es bitte Ihren Kollegen.
Wenn Sie darin Fehler finden, sagen Sie es bitte mir.
Meine Mail-Adresse ist partl@mail.boku.ac.at.

- - -


Vorwort . Wegweiser . Inhaltsverzeichnis . Wörterbuch . Referenzen . Copyright
© Hubert Partl, BOKU Wien