Internet-Programmierung

Jede Web-Interaktion hat 2 Seiten: der Client (der Leser, welcher mit dem Browser auf Ihre Seite zugreift) und der Server (der Ort, wo Ihre Homepage ist. Damit ist die Hardware und die Software gemeint, welche weiss, wie man die Anfragen vom Internet beabtwortet, Ihre Seite findet, und Sie bereitstellt.).

Gibt jemand im Browser (Client) Ihre URL ein, nimmt der Client Kontakt mit dem Server auf, und dieser antwortet, indem er die HTML-Datei zurückschickt, welche dann der Client anzeigt.

Nun wollen wir den Ablauf ein bisschen interaktiver gestalten. Wir wollen den Client befähigen, mit dem Server zu kommunizieren: z.B. um Informationen von einem Formular zu senden oder diese in einer Datei auf dem Server zu speichern.
Oder wir wollen Informationen von den Datenbankdateien des Servers erhalten.

Wir haben nun 2 Maschinen und 2 separate komplexe Software-Umgebungen. Auf der Maschine des Lesers läuft der Browser (der Client). Auf der anderen Seite läuft der Web-Server.

Auf dem Client-Computer können zudem parallel noch andere Programme laufen, wie Textverarbeitung oder Grafikprogramme. Und während diese Programme arbeiten, können auch noch auf der Seite des Servers zusätzliche Programme laufen.

Wenn wir von Interaktion sprechen, wollen wir via den Client den Server auffordern, ein zusätzliches Programm zu starten.

Ok, nachdem wir die beiden Seiten einer Web-Interaktion ein bisschen angeschaut haben, wollen wir schauen, welche Programmiermöglichkeiten uns dazu zur Verfügung stehen.

2.0 JavaScript und VBScript: Client-Side

JavaScript hat mit Java ausser dem ähnlichen Namen nicht viel gemeinsam. JavaScript ist eine Skriptsprache, welche Ihnen erlaubt, den Code auf der Client-Seite einer Web-Interaktion auszuführen. Es ermöglicht Ihnen, einige Sachen auf dem Computer des Leser auszuführen. Man kann damit nicht allzuviel mit Dateien machen, alleine schon wegen der Sicherheit und dem Ressourcen-Zugriff, aber man kann einige interessante Dinge für die Anzeige machen.
JavaScript kann auch für Plausibilitätsprüfungen in Formularen verwendet werden.
VBScript ist ziemlich ähnlich, basiert aber auf Visual Basic und ist speziell für den Internet Explorer entwickelt worden, will heissen, Netscape kann nichts damit anfangen.
Für JavaScript und VBScript gilt: Solange der Browser die Sprachen nicht unterstützt, können sie nicht ausgeführt werden, da JavaScript/VBScript auf der Client-Seite, und nicht auf dem Server ausgeführt wird.

2.1 DHTML / CSS

Mit IE 4 und Netscape 4.0 kam die Möglichkeit hinzu, HTML-Dateien zu erzeugen, bei denen einzelne Elemente während der Anzeige dynamisch ihren Inhalt ändern. Diese Technik nennt man Dynamic HTML (DHTML). Für die Realisierung von DTHML benutzt man JavaScript, und für Formatierungen und Positionierungen kommt dann oft noch CSS hinzu.
Bei Cascading Style-Sheets (CSS) kann man mit Hilfe einer Definitionssprache eigene Formate kreieren und vorhandene HTML-Tags nach Wunsch exakt positionieren. CSS ist ein guter Weg, um ein einheitliches Design über mehrere Seiten hinweg zu gewähren, und dieser Weg wird auch immer mehr benutzt.

Wie schon gesagt, DHTML kann man erst mit den Browsern der Version 4 benutzen. Leider fiel die Implementation beim Microsoft- und beim Netscape-Browser nicht gleich aus, so dass man meist nicht drum herum kommt, für den Netscape ein anderes Script zu schreiben als für den IE. Netscape hat ausserdem verkündet, dass die kommende Version 5 (Mozilla) ihres Browsers nicht mehr kompatibel sei mit der DHTML-Variante von Version 4, was das Leben eines DHTML-Entwicklers auch nicht gerade leichter machen wird.
Ein amüsanter Bericht über die Erstellung von dynamsichen Menüs gibt zu verstehen, dass die DHTML-Implementationen nicht gerade eine Meisterleistung der Browserhersteller war.

Eine gute Einführung in DHTML gibts bei SelfHTML. Natürlich gibt's dort auch interessantes zum Thema CSS.

2.2 XML

Um XML ist zur Zeit der gleiche Hype wie früher um Java, und eine grosse Zukunft wird dieser Technologie vorausgesagt. Experten sagen, dass dieses das neue Ding ist. Die Browserhersteller versprechen, XML bei der weiteren Entwicklung ihrer Browser volle Unterstützung zu schenken. Doch was ist XML?

Die Extensible Markup Language ist das universelle Format für strukturierte Dokumente und Daten im Web, welches auch erlaubt, eigene Tags zu kreieren. Falls Sie Webseiten mit den neusten Technologien erstellen wollen, bietet Ihnen XML viele Vorteile, unter anderem:

es arbeitet in Verbindung mit CSS und DHTML
es unterstützt den Entwickler mit der Möglichkeit, eigene Tags zu erstellen
es erlaubt Websites sich mit den Daten zu präsentieren, die sich der Besucher der Site wünscht, und erlaubt dem Entwickler, ein Dokument verschieden zu formatieren, je nach den Bedürfnissen des Besuchers.

Einige interessante Quellen:
XML in 10 points (vom W3C)
Learn XML in 11.5 minutes
Building Smart Pages with ASP, XML and XSL
HTML-Seiten aus Datenbeständen über XML generieren

3.0 Macromedia Flash

Mit Flash erzeugte Seiten laufen wie bei Java-Applet auch beim Client auf dem Browser ab. Während Java-Applets jedoch von Programmierern erstellt werden, stammt der Flash-Inhalt meist von Grafikern/Designern.
Flash benutzt vektorbasierte, skalierbare Grafiken. Diese Eingeschaft birgt den Vorteil, dass die Dateien kleiner sind, und auch die Streaming-Technologie (der User kann den Inhalt schon anschauen, bevor das ganze Flash-Modul heruntergeladen ist) von Flash hilft, längere Downloadzeiten zu vermieden.

Ein Nachteil von Flash ist, dass man ein Plug-In installieren muss. Ab den Browser-Versionen 5 ist das Plug-In jedoch schon stadardmässig dabei. Gemäss dem Hersteller Macromedia sollen aber schon über 80 % der Internet-Nutzer fähig sein, Flash-Inhalt anschauen zu können.

Hier noch ein paar Flash-Zückerchen: martini.de, gshock.com, troublewear.com, cars.com

4.0 Java: Ihre Wahl:
Client-Side -- oder -- Server-Side

Java ist eine plattform-unabhängige Sprache, welche auf dem Client oder auf dem Server laufen kann. Es ist eine vollumfängliche Programmiersprache, aber auch hier gibt es aus Sicherheitsgründen Einschränkungen mit dem Dateizugriff.
Auf der Clientseite kann man Sachen machen, die über den Leistungsumfang von JavaScript hinausgeht, Java ist aber auch einiges schwieriger zum Erlernen.
Falls der Web-Server oder der Browser Java unterstützt, kann man damit so ziemlich alles machen, was man auch mit C oder C++ kann. Dies ist auch der Grund, warum es Browser gibt, die in Java geschrieben sind, wie auch Browser, die Java-Programme ausführen können. Es gibt auch unzählige plattform-unabhängige Javaprogramme, die nichts mit dem Web zu tun haben.

Java war lange Zeit die Boom-Srache schlechthin, die Sprache mit dem grössten Sex-Appeal, das Lieblingskind der Szene. In letzter Zeit ist es ein bischen ruhiger geworden, der Hype ist verstummt. Mit neuen Technologien wie DHTML/CSS und Flash wird Java das Leben schwer gemacht. Falls man nicht eine Website mit Verschlüsselung und anderen sicherheitsrelevanten Aspekten (wei z.B. bei Banken-Applikationen) realisiert, sieht man heutzutage meist davon ab, für neue Projekte Java zu gebrauchen, vor allem wegen längeren Downloadzeiten und der nicht sehr grossen Java-Akzeptanz bei den Benützern. Dies geht dann meist zugunsten von den oben erwähnten Technologien DHTML und Flash.

JavaScript wird immer raffinierter: http://www.webreference.com/js/column39/
Artikel über ein neues Feature im MS Internet Explorer 5.0, das es erlaubt, mit Hilfe von JavaScript "browserfenster-unabhängige" Anwendungen zu schreiben. HTAs verstehen sich als Konkurrenz zu Java-Applets

5.0 CGI: Server-Side

Nachdem die Server-HTTP-Spezifikationen geschrieben worden sind, fanden die Authoren heraus, dass die Leute mehr wollten, als Web-Seiten zur Anzeige aufzubereiten. Insbesondere wollten sie, dass der Server fähig war, auf Datendateien zuzugreifen und auch Daten abzuspeichern.
Diese Aktivitäten sind jedoch ziemlich plattformabhängig. Trotzdem, der Code und die Algorhytmen in Programmiersprachen bestanden bereits. Und so entstand CGI, und damit ein Weg, Informationen vom Web-Server aus in einem Standard-Format an ein Programm zu senden, das auf dem Web-Server läuft und dann die Information zurückgibt (CGI steht für Common Gateway Interface).

CGI ist eine Spezifikation, welche sagt, dass der Server Eingaben in einem speziellen Format an ein Programm gibt und Rückgabewerte in einem speziellen Format erwartet. Was das Programm in der Zeit zwischen der Ein- und der Ausgabe macht, liegt an den Möglichkeiten und Beschränkungen der jeweiligen Programmiersprache.
Obwohl CGI nun schon ziemlich lange existiert, findet es in gewissen Kreisen noch immer grossen Anklang, obwohl mit anderen Technologien wie ASP zum Teil konfortablere und performantere Entwicklungsumgebungen existieren. Der Grund für die andauernde Akzeptanz ist u.a. die grosse Anzahl an frei erhältlichen CGI-Skripts und das CGI-Knowhow, das über die Jahre hinweg angeignet wurde.

5.1 Vier Voraussetzungen für CGI

Für die Benutzung von CGI, um damit zu erreichen, dass der Client auf dem Server etwas ausführt, braucht es 4 Dinge:

ein Auslöser (Trigger), welcher entweder eine URL ist, die an ein Programm verweist, welches das CGI-Format versteht, oder ein Server Side Include (SSI), welches ein Programm ausführt, welches das CGI-Format versteht;
ein Server, der weiss, was mit der CGI-Anfrage zu tun ist und die Informationen gemäss dem CGI-Standard formatiert und sie dann an das dazu bestimmte Programm weitergibt;
ein Programm (in diesem Fall das CGI-Skript), welches in einer solchen Weise geschrieben wurde, dass es mit dem Web-Server kommunizieren kann;
die Erlaubnis, das Programm auszuführen.

CGI erlaubt dem Client, eine Anfrage an den Server zu schicken, damit ein Programm AUF DEM SERVER läuft. Dieses Programm ist das CGI-Skript. Das CGI-Skript ist ein ausführbares Programm (es kann in einer von mehreren Sprachen geschrieben werden), welches fähig ist, die CGI-Anfrage, die vom Server kommt, zu vertstehen.

5.2 Zwei Schritte für die Ausführung eines CGI-Skripts

Beachten Sie bitte, dass, wenn Sie obengenannte 4 Voraussetzungen erfüllen, die Ausführung eines CGI-Skripts stets noch ein 2-Schritte-Prozess ist: Zuerst bittet der Browser den Server, das CGI-Programm auszuführen, entweder durch eine URL oder durch ein Aktions-Attribut eines HTML-Formulars.

Nachdem der Server die Anfrage entgegengenommen hat, leitet er sie an das CGI-Skript weiter.

In diesem Sinne beinhaltet CGI ein "Darf ich, Mama?"-Schritt, welcher in einem typischen Stand-alone-Programm nicht enthalten ist. Das ist auch der Grund, warum vielen HTML-Programmierern die Haare zu Berge stehen, wenn sie ein CGI-Programm das erste Mal ausführen; das Skript ist da, es läuft prima im Selbst-Test, aber aus irgendeinem Grund will es der Server nicht ausführen.

Daher gilt es einige Dinge zu beachten:

der Browser muss wissen, wie er die CGI-Anfrage weiterleiten muss (dies ist z.B. kritisch, wenn der Browser keine Formulare unterstützt);
der Webserver muss wissen, was er mit der CGI-Anfrage machen muss;
das ausführbare Programm (CGI-Skript) muss wissen, wie es das CGI-Input- und Output-Format handhaben muss;
Sie müssen die Erlaubnis haben, das Programm auszuführen.

Ein Programm, welches das CGI-Format handhaben kann, wird "CGI-Skript" genannt, egal, ob es in einer Skript-Sprache wie Perl oder in einer vollen Programmiersprache wie C geschrieben wurde.

5.3 Häufiger Anwendungsbereich: Formular-Aktionen

Am meisten wird CGI von einem Client dazu gebraucht, um auf dem Server an Daten zu gelangen, entweder um sie abzufragen oder auf dem Server zu speichern, um die Daten danach im Browser anzuzeigen. Ein typisches Beispiel ist ein Zähler, welcher bei jedem Anwählen einer Seite den Zähler auf dem Server um 1 erhöht und in an den Browser zur Anzeige zurückschickt.

(Mit JavaScript kann z.B. kein Zähler generiert werden, da JavaScript nur auf dem Client läuft. Stattdessen muss ein Zähler auf dem Server gespeichert werden können.)

Ein CGI-Programm kann z.B. auch Produkteinformationen, die auf dem Web-Server (oder irgendeinem Computer, auf den der Webserver Zugriff hat) gespeichert sind, zugreifen, diese Daten hübsch formatieren und sie dann wieder an den Web-Server geben, welcher sie dann an den Client weiterleitet.

Einer der gebräuchlichsten Anwendungsbereich von CGI ist, Informationen von einem HTML-<FORM>-tag zu bekommen und diese an das serverseitige Programm weiterzuleiten. Ausgelöst wird dies durch das ACTION-Attribut.
Zum Beispiel:

<FORM METHOD=POST ACTION="http://www.simsy.ch/cgi-bin/post-query">

Dieses HTML-tag veranlasst, dass das CGI-Skript mit dem Namen 'post-query' ausgeführt wird, sobald der Leser das Formular von der HTML-Seite übermittelt. Der Browser schickt die Daten im Formular an den Server, der Server startet das CGI-Skript, welches in ACTION genannt wurde, und dieses verarbeitet dann auch die Informationen.

Da CGI auch Dateien erstellen kann, ist es auch fähig, HTML-Dateien zu erstellen, und diese dann an den Leser zur Anzeige zurückschicken. Dies ist eine gebräuchliche Methode, um Informationen vom Server zu bekommen und sie an den Client zu schicken.

CGI kann daher benutzt werden, um HTML-Seiten "on the fly" zu generieren.

6.0 Perl: Serverseitige Skriptsprache

Perl ist eine Skriptsprache, die ursprünglich von der UNIX-Welt kam. Es ist ziemlich gut für das Handling von Text-Strings, und da CGI dazu tendiert, die Inputdaten wie ein einziger langer String aussehen zu lassen, ist Perl auch ziemlich gut als CGI-Sprache.
(Bitte erinnern Sie sich daran, dass CGI auf dem Server läuft. Daher muss der Client nicht fähig sein, Perl auszuführen.)

Anders als Java ist Perl nicht unbedingt dazu entwickelt worden, um plattform-unabhängig zu sein. Es ist eine nette Sprache, die schnell zu erlernen ist und passend ist für Dinge, welche die meisten Web-Applikationen auf dem Server ausführen wollen, obschon einige Abstriche bezüglich Geschwindigkeit gemacht werden muss. Perl läuft besser auf UNIX als auf NT, andere Plattformen sind dazu eher nicht zu empfehlen. Wenn ein Perl-Skript für eine Web-Applikation ausgeführt wird, ist dies meist ein CGI-Skript: Die HTML-Datei benutzt CGI, um an den Server ein "Darf ich, Mama?" zu schicken, welcher dann das Perl-Programm startet.

Wie nun ein solches Programm funktioniert, um etwa Formulardaten auszuwerten, können Sie bei Jason Nugent lesen.

Im Internet erhalten Sie massenhaft weitere Perl-Skripts, die Sie zur freien Weiterbenützung in Ihren Seiten einbauen können (Wie gesagt, Voraussetzung dazu ist, dass der Webserver, auf dem Ihre Seiten sind, die CGI-Skripte unterstützt und dass Sie auf dem Server auch die entsprechenden Berechtigungen besitzen.)

Webreference.com hat ein Tutorial, das zeigt, wie man ein Webverzechnis analog Yahoo mit Perl machen kann.

6.1 Andere serverseitige CGI-Skript-Sprachen:
Tcl, C, Visual Basic, Applescript

Perl ist jedoch nicht die einzige Sprache, die für CGI in Frage kommen kann. Mac-User benutzen häufig das altbewährte Applescript. O'Reilly's Server erlaubt Windows NT-Benützern auch Visual Basic als CGI-Skript-Sprache. Auch Java und C/C++ werden häufig gebraucht, vor allem, wenn volle Performance gefordert wird. Das einzige, was eine Sprache beherrschen muss, um eine CGI-Sprache zu sein, ist das Handling von der Ein- und Ausgabe im CGI-Format. Wenn dies erfüllt ist, muss das Programm mit dem richtigen Namen und den richtigen Berechtigungen in das richtige Verzeichnis gestellt werden, und schon werden sie normalerweise fähig sein, das Programm als CGI-Skript zum Laufen zu bringen.
Compiler-Sprachen wie C++ sind schwieriger zu erlernen, aber laufen meistens schneller als Interpreter-Sprachen wie Perl und Basic.

7.0 Active Server Pages (ASP)

Active Server Pages (ASP) ist eine Technologie, mit welcher Befehle auf dem Webserver ausgeführt werden, und als Ergebnis wird normalerweise HTML an den Browser zurückgeschickt. In der Praxis sieht das so aus, dass zwischen die normalen HTML-Anweisungen Skripte eingebunden. Der Server wertet die Skripte aus und schickt dann nur noch die Ergebnisse in purem HTML an den Browser. Als Skriptsprachen kann hier z.B. VBScript oder JScript eingesetzt werden.

Hat man schon einmal etwas mit z.B. Visual Basic/VBA oder JavaScript programmiert, fällt einem der Einstieg in die ASP-Programmierung nicht schwer, da einem, wie gesagt, mit VBScript oder JScript eine Sprache zur Vergügung steht, die sehr an VBA oder JavaScript angelehnt ist.

Zu beachten ist jedoch, dass für das Funktionieren von ASP auf dem Server auch die entsprechenden ASP-Erweiterungen installiert werden müssen. Diese sind jedoch in der Zwischenzeit nicht nur für Microsofts hauseigenen IIS erhältlich, sondern sogar auch für Webserver wie den Apache.

Auf Weblehre.de gibts eine kurze aber gute Einführung zu diesem Thema. Das gleiche, aber in Enlisch und in einem viel grösseren Umfang stellt 15 Seconds bereit.

7.1 the Microsoft way: WebClasses / IIS-Applikationen / ActiveX

Am Anfang war die Seite. Die pure, statische HTML-Seite. Doch damit gab man sich nicht lange zufrieden, und schon bald wurden Möglichkeiten erschaffen, die Seiten dynamisch zu erstellen. Nachdem die Entwickler mühselig CGI gelernt hatten, brachte Microsoft ASP heraus, und man staunte ob deren Raffinesse. Die Bedüfnisse von Entwicklern hielten aber weiter an, und man wollte nun vortan nicht mehr nur einzelne Seiten on the fly erstellen lassen, nein, man wollte jetzt auch ganze Appliaktionen ins Web stellen. Um dabei das Leben eines Web Developers ein bischen leichter zu machen, warf Microsoft fleissig weitere Technologien auf den Markt.

ActiveX war/ist ein Teil davon. Eigentlich sollte ActiveX-Controls Java verdrängen. Doch die Akzeptanz gegenüber ActiveX war sowohl bei den Benutzern wie auch (verständlicherweise) bei der Browserkonkurrenz nicht sehr hoch, und so setzt heute jemanden, der ein breites Publikum erreichen möchte, kaum ActiveX-Controls in seinen Webseiten ein.

Microsoft hat schnell einmal realisiert, dass die Anwendungen im Web immer komplexer werden. Dies wurde einem auch auf eindrückliche Weise mit der Präsentation der Entwicklungsplattform Visual Studio 6.0 klar. Die Zeiten, in denen man einzig und allein einen Texteditor als HTML-Werkzeug nutzte, ist definitiv vorbei.
Ein Mögliches Szenario eines Web-Entwicklers mit Microsoft-Tools: Mit Visual C++ schreibt er eine Komponenten. Diese Komponenten bindet er mit Hilfe von Visual InterDev an einen MS SQL-Server an und bettet die Komponenten in HTML-Seiten ein, die zuvor mit Frontpage erstellt wurden. Für die Verwaltung der Komponenten wird der Transaction Server eingesetz. Der Internet Information Server dient dabei zur Verarbeitung des ganzen ASP-Codes.

Die Zeiten, als man noch Eindruck schinden konnte, wenn man ein paar HTML-Tags kannte, sind also definitiv vorbei. Doch Microsoft liegt es wohl fern, Internet-Entwickler mit neuen Technologien einzuschüchtern, als vielmehr, dass Sie ihnen damit das Leben leichter machen möchten.

Wurde Visual Basic früher hauptsächlich benutzt, um Client-/Server-Applikationen zu schreiben, so stehen einem heutzutage mit VB mehrere Möglichkeiten zur Verfügung, diese Applikationen auch als Web-Applikationen zu programmieren. Ein Weg dazu sind die sogenannten WebClasses, mit denen man IIS-Applikationen erstellen kann. Das Prinzip ist das gleiche wie mit ASP: Bei Aufruf einer Webseite wird auf dem Webserver Code abgearbeitet, das Ergebnis wird als HTML an den Browser zurückgeliefert. Da das ganze auf dem Server abspielt, kommt es natürlich auch nicht darauf an, was für ein Browser benutzt wird.

WebClasses bieten gegenüber normalen ASP-Seiten folgende Vorteile:
IIS-Applikationen sind kompiliert im Binärformat vorhanden, d.h. sie sind performanter als ASP-Seiten, wo zuerst immer Skriptcode abgearbeitet werden muss.

Nachteile:
die WebClasses sind .dll's, die auf dem Web-Server registriert werden müssen
Aufbau ganzer Websites ist nicht so gut zu verwalten in VB

Mögliches Einsatzgebiet:
bei Seiten, wo umfangreicher Code abgearbeitet werden muss, z.B. bei Einbindungen einer Business Logik. Der Code wird dabei in .dll's ausgelagert, was einen Performance-Gewinn ergibt.

8.0 Server Side Includes

Server Side Includes (SSIs) sind von der Technik her ähnlich wie CGI, insoweit sie auch Befehle an den Server geben um spezielle Funktionen auszuführen. Das bedeutet auch, dass sie nicht von allen Servern unterstützt werden und nicht alle Verzeichnisse haben die Erlaubnis sie zu gebrauchen. Grundsätzlich teilen Server Side Includes dem Webserver mit, ein HTML-File zu lesen und zu stoppen, sobald eine SSI-Zeile kommt, dort etwas ausführen, und danach wieder weiterfahren.

Um dies zu tun, muss der Webserver die HTML-Datei Zeile für Zeile (ja wirklich, Zeichen für Zeichen) lesen, befor er sie an den Client weitergibt. Dies wird parsing genannt, und wenn es langsam tönt, so ist es auch so. Aus diesem Grunde sind viele Systeme nicht dazu eingerichtet, um jede einzelne Web-Seite zu parsen. Statt dessen werden oft spezielle Namenskonventionen benutzt (häufig .shtml statt .html, der Webmaster kann dies aber selbst bestimmen), und dann werden nur diese Files geparst.

Die SSIs sind in der HTML-Datei eingefügt. Typische Bespiele für SSIs sind

<!--#exec cgi="/cgi-bin/countme.cgi"-->

oder

<!--#include file="newfile.txt"-->

8.1 #INCLUDE

Eines der nützlichsten SSIs ist das #INCLUDE, womit man eine Datei innerhalb der HTML-Datei einfügen kann.

Bitte erinnern Sie sich, dass sich dies auf dem Server abspielt, also bevor die Seite an den Client gesendet wird. Dies ist ein hervorragender Weg, um die Organisation von grossen Seiten zu verbessern und vereinfachen. Ein Beispiel kann z.B. ein Wetterdienst sein, wo das Grundgerüst immer gleich bleibt, nur die aktuellen Wetterdaten werden in das HTML-File eingespeist.

8.2 #EXEC

Dieser Befehl erlaubt Ihnen, an dieser Stelle ein CGI-Skript auszuführen. Der Server wartet dann auf das Ergebnis des CGI-Skripts, bevor er mit dem Parsing der Seite weitermacht.
Der Gebrauch von #EXEC setzt voraus, dass alle Vorkehrungen für den Gebrauch von SSI und alle Vorkehrungen für den Gebrauch von CGI getroffen worden sind.

(Technische Bemerkung: Die Sicherheitsvorkehrungen für SSI sind auf andere Weise implementiert als diejenigen für das cgi-bin-Verzeichnis. Daher ist es nicht ungewöhnlich, dass einige Seiten CGI erlauben, SSIs aber nicht. Fragen Sie Ihren Webserver-Betreiber, was Sie berechtigt sind zu gebrauchen und was nicht.)

9.0 Wie Client-Side- und Server-Side-Programme zusammenarbeiten können

Alles dies kann nun zusammenarbeiten. Clientseitiges JavaScript kann gebraucht werden, um die Verarbeitungszeit und die Gültigkeit zu verbessern, oder auch für Animationen, auf der Seite des Clients (im Browser). Es kann dann die vorgeprüften Daten eines Formularinhaltes über CGI an ein Perl-Programm weitergeben, welches auf dem Server abläuft, und die Informationen dort in einer Datei speichert. Dann kann der Server die Daten zurückerhalten und sie an den Client, wo ein weiteres clientseitiges JavaScript eine hübsche Verabeitungs-Nachricht erstellen kannn.

(Denken Sie daran, dass client-side JavaScript den Server nicht berührt, daher können Sie es nicht gebrauchen, um Daten auf dem Server zu speichern oder Daten vom Server zu holen.)

Oder Sie können Java auf der Clientseite und auf der Serverseite gebrauchen. Diese zwei wären dann aber voneinander unabhängige Implementationen; wenn der Browser die Java-Fähigkeit abgestellt hat, oder sie nicht vorhanden ist, können die Java-Programme auf dem Server noch immer ablaufen. Normalerweise sind die Java-Programme auf dem Server jedoch nicht die gleichen wie die Java-Applets, die auf dem Browser ablaufen.

Um vom Client mit dem Server zu kommunizieren, können Sie CGI gebrauchen. Häufig wird dies mit Perl, C, Visual Basic, Lisp, Ada etc. gemacht. Diese Programme müssen jedoch alle auf dem Server installiert sein, nicht auf dem Client. Wenn Sie einen UNIX-Host haben, können Sie kein VB-Programm als CGI-Skript laufen lassen, auch wenn der Browser auf einem PC läuft - die CGI-Programme laufen immer auf dem Server.

10.0 Was ist das Beste für Formulare

10.1 Clientseitige Beschränkungen

Was das Beste ist kann man wohl so einfach nicht sagen. Schnelle, effiziente Formularverarbeitung würde idealerweise auf der Client-Seite (für Plausibilitätsprüfung, Animationen, Navigationsschaltflächen, und Anzeigenachrichten) und auf der Server-Seite (Daten-Speicherung und -Abfrage) basieren.

Vieles hängt davon ab, was Sie bereits wissen, wieviel Zeit Sie in den Lernaufwand investieren möchten, was Sie zur Verfügung haben und was Ihr Server unterstützt.

Für CGI-Skripts oder ASP-Seiten spricht, dass es auf Ihrem Server läuft und ein Ergebnis liefert, das beinahe alle Leser sehen können. Sie machen die Arbeit, Sie kontrollieren die Sicherheit und Sie handhaben die Antwort.

JavaScript, VBScript und Java-Applets verlangen vom Leser, dass er die richtige Software benutzt, ansonsten kann er Ihre hübschen Features nicht sehen.

ActiveX schränkt sogar noch mehr ein. Weil sich der Leser seine Festplatte in Ihre Hände anvertrauen muss und wegen der 32bit-Windows-Abhängigkeit gehen Sie das Risiko ein, Leser oder zumindest ihre Zufriedenheit zu verlieren.

10.2 Die Zukunft der Serverseite

Nun, ob eine Serverseitige Java-Applikation CGI ersetzen wird, ist in den meisten Fällen nicht anzunehmen. Und die wenigsten Web-Server führen natives Java aus - sie gebrauchen stattdessen CGI oder Active Server Pages oder andere Wrapper/Middleware, um es zu implementieren. Es ist ungewöhnlich, dass man einen Host findet, der Java als Ersatz für CGI/ASP benutzt. Die Lernkurve für Java ist auch relativ steil; CGI kombiniert mit einer einfachen Sprache wie Perl ist ein einfacher und schneller Weg, um einfache Programme auf dem Server zu installieren.

11.0 Entscheiden Sie selbst

Wie schon erwähnt, was Sie einsetzen sollten, hängt davon ab, welche Vorkenntnisse Sie besitzen, was Sie auf Ihrem Server zur Verfügung haben und was Sie glauben, das der Besucher Ihrer Website zur Verfügung und aktiviert hat.

Falls Sie ASP/CGI auf Ihrem Server nicht einsetzen können, kann JavaScript einige hübsche Dinge mit Plausis und der Anzeige auf der Browserseite machen.

Falls Sie nach etwas Ausschau halten, um Ihre Website ein bischen aufzupeppen, ist JavaScript/DHTML eine gute Wahl, da es einfacher zu lernen ist als Java.

Sie können nun selbst wählen, aber schauen Sie nach Möglichkeit, dass beide Seiten der Web-Transaktion berücksichtigt werden: der Client und der Server.