An sich ist die Idee von Frames ja genial. Man definiert die Startseite eines WEB-Auftritts als Frameset und gliedert einzelne HTML-Seiten als Frames darunter an, zum Beispiel die Navigationsleiste eigenständig und getrennt von der Content-Seite. Das schöne für den HTML-Ersteller ist dabei zum einen, dass die Navigation nicht innerhalb der Content-Seite liegt und diese unübersichtlich macht und zum anderen, dass die Navigationsleiste nur einmal zentral gepflegt wird und nicht in jeder Content-Seite ständig angepasst werden muss.

Frames haben aber auch ihre Nachteile:

• mit Frames lässt sich nicht der DOCTYPE "Strict" verwenden
• das Ansteuern der einzelnen Fenster mit "target=" ist nicht ganz einfach
• Suchmaschinen speichern auch die direkten Verweise auf die Contentseiten damit bekommen Anwender nur die Contentseite ohne Navigation angezeigt

Der letzte Nachteil war für mich der ausschlaggebende, um mich nach Jahren wieder von den Frames zu trennen. Nun galt es einen Ausgleich zu finden für den größten Vorteil, den die Frames für mich hatten, nämlich die Navigation vom eigentlichen Inhalt getrennt zu halten.
Meine Lösung: SSI Server Side Include.

Was ist SSI?

Die Idee der Includedateien ist überhaupt nicht neu. Hatte nicht "dBASE II" Anfang der 80er Jahre des letzten Jahrhunderts bereits Includedateien? Includedateien sind nichts anderes als ein Stück Programmtext, in unserem Fall HTML, der in eine eigene Datei ausgelagert wird. Im eigentlichen Programm also der HTML-Page steht dann nur ein Verweis auf diese Datei. Warum macht man das? Zum Beispiel um gleiche Programmpassagen nicht mehrfach in verschiedenen Programmen zu haben, um diese ausgelagerten Programmpassagen einmal zentral zu pflegen, um mehr Modularität zu bekommen oder - und ich denke das war der Grund damals bei "dBASE II" - um mit geringem Hauptspeicher zurecht zu kommen, was ja heute nicht mehr so das Thema sein sollte.

Und jetzt kommt das geniale, nämlich das "Server Side": Im Fall von SSI ist der WEB-Server so schlau, zur Laufzeit die angeforderte WEB-Seite aus den einzelnen Includes so zusammen zu bauen, dass der Browser des Anwenders vom SSI überhaupt nichts mitbekommt. Der HTML-Ersteller hat aber den Vorteil, dass zum Beispiel die ganze Navigationsleiste in einer eigenen Datei liegt und in der Contentseite nicht mehr störend wirkt. Und sie kann zentral gepflegt und in viele HTML-Seiten gleichzeitig eingebunden werden.

Kein 100%iger Ersatz für die Frames also, weil ja im Code, den der Browser bekommt, wieder Navigation und Content in einer HTML-Seite stehen Aber für mich ausreichend. Zwei weitere Vorteile hat die Sache: Nachdem alles wieder in einer Datei ist, gibt es das oben beschriebene Problem mit dem Verlinken direkt auf den Content ohne Navigation nicht mehr. Und die Navigation ist fest mit dem Content verbunden, scrollt also mit nach oben. Das kann man als Vor- oder auch als Nachteil sehen, jedenfalls lässt sich nun unterhalb der Navigation eine Werbung einblenden, die beim Hochscrollen erscheint.

Wie funktioniert SSI

Nachdem SSI eine Funktionalität des WEB-Servers ist, braucht man einen WEB-Server, bzw. einen Provider, der SSIs unterstützt. Die großen bekannten WEB-Hoster tun das alle, bei kleinen WEB-Spaces, die man zu einem Internetzugang dazugeschenkt bekommt, ist oft nur statisches HTML möglich und kein SSI. So kann ich auf "www.gpswandern.de" SSIs nutzen aber hier auf "muenchen-surf" leider nicht.

Unterstützt der WEB-Server SSI, dann müssen ihm im Normalfall die Seiten extra bekannt gemacht werden, die dynamischen Inhalt im Sinne SSI verwenden. Üblicherweise geschieht das dadurch, dass die Dateierweiterung nicht mehr ".html" sondern ".shtml" heißt.

Dann sollten die HTML-Includes, die von mehreren SHTML-Dateien benutzt werden sollen, in ein zentrales Verzeichnis gelegt werden, zum Beispiel /include. Die Dateierweiterung der Includes kann frei gewählt werden, ich verwende ".inc".

Und als letztes müssen natürlich in die SHTML-Dateien die Verweise auf die INCs eingetragen werden.
Ein Beispiel:

Eine ganz normale HTML-Datei, jedoch mit der Dateierweiterung .shtml und mit einer "include virtual"-Anweisung innerhalb eines Komentartags.

Dazu eine passende Includedatei im Includeverzeichnis. Diese beiden Dateien werden auf den WEB-Server hochgeladen.

Beim Aufruf der Seite "seite.shtml" fügt der WEB-Server die Includedatei an der bezeichneten Stelle ein, so dass der Browser die komplette Datei erhält. Nicht mehr und nicht weniger. Anhand dieses Beispiels kann man sich vorstellen, die komplette Navigationsleiste in eine zentrale Includedatei auszulagern und in jede Contentseite nur den "include virtual" Verweis aufzunehmen.

Begleiterscheinungen

Drei Dinge sind jetzt aber - sagen wir mal - unschön:

• Wollte man die Hauptseite auch per SSI versorgen, müsste sie "index.shtml". heißen. Das "s" ist - zumindest in meinem Fall - nicht gewünscht, ich möchte eine klassische index.html als Homepage.
• Bei mir liegt die Homepage im Rootverzeichnis, alle anderen Seiten in einer Verzeichnisebene darunter. Damit kann eine Navigationsleiste, die für die Unterseiten passt, leider nicht gleichzeitig für die Homepage passen.
  Zwei Umstände, die es für mich nötig machen, die Homepage immer separat zu betrachten und für Sie kein SSI zu verwenden. Eine kleine Einschränkung aber kein KO-Kriterium für den generellen Einsatz von SSI.
• Der dritte Punkt erschwert etwas die Entwicklung von WEB-Seiten: Die SHTML-Seiten können nicht mal eben von der Festplatte aus im Browser angezeigt werden. Um die Includes einzubinden ist - wie gesagt - ein WEB-Server nötig. Also doch endlich den eigenen Appache aufbauen!

Weitere SSI-Funktionen

Außer Includes einzubinden kann SSI aber noch viel mehr. Zum Beispiel Arbeiten mit Variablen, ausführbare Programme am Server starten oder - eine Funktion, die ich auf jeder SHTML-Seite verwende - den Timestamp der Datei auslesen und als Änderungsdatum anzeigen:

Markenzeichen: dBASE und dBASE II waren seinerzeit markenrechtliches Eigentum der Firma Ashton-Tate. Aber ich glaube, die Firma gibt es unter diesem Namen schon lange nicht mehr.