Wo liegen die Grenzen von HTML? Warum reicht HTML für manche Anwendungen nicht mehr aus? HTML ist statisch! Das heißt, es wird immer exakt dieselbe Seite übertragen - wie eine Seite eines Buches, die auch nur bei einer Neuauflage verändert wird. Aber was wollen wir denn anderes? Wir möchten erstens die Seiten Personen-abhängig gestalten. Wir möchten den Benutzer vielleicht verschieden anreden (in Abhängigkeit von Name, Geschlecht oder Tageszeit: "Guten Morgen Frau Stirnima" oder "Guten Abend Herr Müller-Lüdenscheid"). Und zweitens möchten wir interaktiv Daten erfassen. Wir möchten die Daten anzeigen, die der Benutzer letztes Mal eingegeben hat. Man möchte dem Benutzer fehlerhafte Eingabe besonders kennzeichnen. Also Seiten sind nicht nur personen-abhängig, sondern auch von Eingaben oder anderen Aktivitäten (z.B. Drücken von Knöpfen) und von der Vorgeschichte abhängig. Wie sieht die Zukunft von HTML aus? Es gibt zwei Möglichkeiten HTML dynamisch zu gestalten: Entweder man macht es auf der Benutzerseite, indem man dem Browser dHTML-Seiten schickt (dynamic HTML) oder macht es beim WEB-Server, indem man dem Benutzer jedesmal andere HTML-Seiten schickt - dies geschieht bei CGI oder ASP.      dHTML: Bei dHTML ist die Sprache HTML um dynamische Elemente erweitert worden. Durch Aktivitäten des Benutzers (z.B. Ziehen der Maus über sensible Bereiche oder Anklicken einzelner Elemente) ändert sich das Aussehen der angezeigten Seite. dHTML setzt aber voraus, dass alle Browser diese Sprache verstehen. Das setzt also voraus, dass Microsoft und Netscape sich einigen und dass alle Benutzer neue Browser installieren. CGI: Bei CGI werden auf der Server-Seite jedesmal neue HTML-Seiten generiert und zum Benutzer geschickt. Bei CGI werden also keine HTML-Seiten geschrieben, sondern Programme (in einer beliebigen Sprache), die HTML-Seiten und Zeilen ausgeben. z.B. printf("<H1> Dies ist Kapitel 1 </H1>"). CGI erinnert ein bisschen an die guten alten Zeiten, als die Ägypter ihre ersten Basic-Programme noch in Steinplatten meißelten. ASP: Bei ASP werden wie gewohnt HTML-Seiten geschrieben, in die zusätzliche Progamm-Anweisungen eingefügt werden, z.B. IF-Anweisungen, Wiederholungs-Schleifen, usw. ASP behebt auch eine Schwäche, die bei CGI in einem Microsoft-Betriebssystem auftritt: Für jeden Aufruf derselben CGI-Anwendung muss einer neuer Prozess gestartet werden (d.h. dasselbe Programm wird mehrfach geladen). ASP dagegen wurde in die Microsoft-Systemumgebung integriert und eine Anwendung wird durch verschiedene DLL-Aufrufe abgearbeitet. Diese DLLs werden aber nur einmal geladen (Schlagwort: multiple threads and multiple users). Aus Programmierer-Sicht ist ASP nichts anderes als eine Rechner-Umgebung, die es ihm erlaubt, ein Gemisch von HTML und einer Scriptsprache zu schreiben (egal welche Scriptsprache). Mit den Script-Anweisungen kann man compilierte Programme (DLLs die ActiveX-Objekte enthalten) aufrufen, um z.B. über ODBC auf Datenbanken zuzugreifen. PHP3: In einfachen Worten: PHP3 ist das ASP für die Linux-Welt. Es gibt alles, was man braucht - z.B. eine Schnittstelle zu ODBC-Treibern. Die Sprache sieht stark wie C aus. Die C-Programmierer werden jubeln. Diejenigen, die auch andere Sprachen kennen, werden nicht so glücklich sein. Aber man kann sich wieder umgewöhnen (und auch wieder die typischen C-Programmierfehler machen). Voraussetzungen Hardware und Software Auf einem Windows NT Server Version 4.0 muss der Internet Information Server (IIS) Version 3.0 installiert sein. Ein zweiter Rechner auf dem irgendein Browser läuft . Dieser Rechner muss über ein Netz mit dem NT Server verbunden sein. Was muss der ASP-Entwickler wissen? Der Entwickler sollte HTML beherrschen (naja - im Prinzip) Er sollte bereit sein, ein paar Anweisungen einer Scriptsprache zu erlernen. Falls er schon Visual Basic kennt, ist er fast schon automatisch in der Lage VBScript zu schreiben. Falls er Datenbank-Anwendungen schreiben möchte, muss er SQL verstehen, um die notwendigen Datenbankbefehle zu programmieren. Diese Befehle kann er direkt ins Script schreiben (siehe mein Datenbankbeispiel) oder in einer DLL ablegen (siehe wichtige Datenbankbefehle). Im Prinzip sollten DLLs Geschwindigkeitsvorteile bringen. Aber was die Geschwindigkeit von Datenbankprogrammen betrifft, kann man da immer wieder unangenehme Überraschungen erleben. Man sollte die Geschwindigkeiten selbst experimentel bestimmen. Schritte bis das erste kleine Programm läuft Ihre PCs sind vernetzt. Ein PC dient als Server (Windows NT) und einer als Client. Dort ist ein Browser (Netscape oder Internet Explorer) installiert. Läuft der Web Server? Systemsteuerung/Dienste anklicken und nachsehen, ob "World Wide Web Publishing Service" gestartet ist. Ist eine IP Adresse angegeben? Die finden Sie unter Systemsteuerung/Netzwerk/Protokolle. Beim TCP/IP-Protokoll Eigenschaften anklicken. Kennen Sie den Namen des Rechners: Den finden Sie unter Systemsteuerung/Netzwerk/Identifikation. Ihr erstes Testprogramm unter dem Verzeichnis Inetpub\wwwroot speichern oder dort ein Verzeichnis anlegen und dann dort speichern.(z.B. Inetpub\wwwroot\myTests\Test1.asp) Lässt sich default.asp rufen? Dazu geben beim Browser des Clients HTTP://NameServer ein. Wenn das nicht funktioniert, geben Sie anstatt des Names die IP-Adresse des Servers ein. In beiden Fällen müssten Sie die Seite sehen, die als default.asp beim Server unter wwwroot gespeichert ist. Ebenso müssten Sie auch Ihr Test-Programm rufen können: z.B. HTTP://NameServer/myTests/Test1.asp .