TreeView-Beschreibung für HTML-Programmierer

Getestet mit Netscape3, Netscape4, IE3, IE4, IE5, Opera5: OK, volle Funktion, mit leichten Abstrichen bei Netscape4 (keine sofortige Fettschrift) sowie Netscape3 und IE3 (kein Scrollen). Bei Netscape2 mischen sich Properties (Array.length) mit Indizes (Array[0]), deshalb keine ordentliche Funktion, hier gibt's eine JavaScript-Fehlermeldung.

Wenn Sie die Baumansicht für ihre eigenen Projekte verwenden wollen, müssen Sie einen Baum der unten verwendeten Struktur erstellen: Jede Ebene besteht aus einem Array von Objekten, die jede eine Eigenschaft (Variable) sub haben können; das ist dann ein Unter-Ast. Die Objekte haben weitere Variablen Titel und Link sowie target, das ist für den dargestellten Text (letztere sind optional und dürfen null sein), die Variablen Img und ILink sind ebenfalls optional und sind für das dargestellte Symbol zuständig.
Hinweis: Diese Baumansicht ist nur für statische Bäume geeignet, d.h. wenn die Baumstruktur von vornherein komplett bekannt ist!

Vorteilhaft für die Baum-Erstellung sind Konstruktoren, die als letzten Parameter sub haben (wie unten angegeben), damit kann man den Baum gewissermaßen im WISYWIG-Verfahren erstellen. Nur bei den Klammern muss man noch höllisch aufpassen.

Für immer wiederkehrende ähnliche Äste machen sich speziellere Konstruktoren gut; hier ist es StdLesson().

Für die Darstellung der +/-Symbole sind 8 Grafiken notwendig, die einfach neben der content.htm liegen und 1.gif..8.gif durchnummeriert sind. Sie sind 11..14x20 Pixel groß, 16farbig und mit transparenter (weißer) Hintergrundfarbe. Wie man wohl sieht, stammen sie vom Windows-Explorer; dort sind sie jedoch 16x16 Pixel groß. Mehr Höhe bedeutet mehr Spielraum für Schriftgröße (Lücken vermeiden), weniger Breite spart Platz bei tiefen Bäumen.
Mit der Angabe align=texttop rutschten die Bilder optisch in die Mitte des Textes; allerdings ignoriert Opera5 dieses, und die Zeilen haben unschöne Lücken, deshalb wurde auf das portablere align=top umgestellt.

Die Speicherung der Information, welche Knoten geschlossen und welche geöffnet sind, würde normalerweise einen Cookie erfordern, um die Information von einer Seite in die nächste zu retten.
Stattdessen wird hier diese Information nach einem Fragezeichen an die URL der momentanen Seite angehängt; der Browser (bei Datei) bzw. der Web-Server ignorieren diesen Teil bei der Auffindung einer gewöhnlichen Datei (bei CGI wird diese Info an das CGI-Programm durchgereicht).
Eine Bit-Kette aus Nullen und Einsen speichert schließlich diese Info. Als Teil eines Frames sieht man diese Information jedoch (fast) nie.

Außerdem wird gespeichert, welches Blatt zuletzt angeklickt wurde. Unter IE4+ mit seinen wird dieses Blatt sofort durch Fettschrift kenntlich gemacht, bei allen anderen Browsern erst nach einem weiteren Neulade-Vorgang.

Weiterhin wird die Position der Rollbalken gespeichert, um beim Reload möglichst die gleiche Position wiederherzustellen. Leider erwies sich SelfHTML als Dokumentationsfehlerschleuder; erst nach eingehender Untersuchung der Unterschiede Netscape<->IE ließ sich das Scrollen auch beim IE4 verwirklichen.

Zur dauerhaften Speicherung des "Aufblätter-Zustandes" (also bis zum späteren Seiten-Besuch) musste ich doch noch zu einem Cookie greifen. Neben allen vier Parametern (Aufblätter-Zustand, angeklicktes Blatt, horizontale und vertikale Scroll-Position) wird auch die URL der rechten Seite gespeichert. (Die Verwendung von Frames ist hier ohnehin angeraten und naheliegend.)

Bei der Programm-Implementierung wurde zunächst in einer Tabelle ausgegeben; dabei zeigten sich bei Netscape4 (nicht 3) unschöne Stockungen (die Tabelle wird erst nach längerer Zeit in einem Rutsch ausgegeben), deshalb wird der Baum nun als normaler Text innerhalb eines <nobr> ausgegeben.
Auch bei Netscape4 (nicht 3) wurde festgestellt, daß die document.write- Anweisung sehr lange braucht; deshalb werden die Teilstrings erst zusammengesetzt und dann in einer ganzen Zeile ausgegeben.

Den Baum darstellen macht schließlich ein Aufruf von WriteTree(Baum). Vorherige Initialisierungen trennen die Angaben innerhalb der URL und ermitteln den Speicherplatzbedarf für die Bitkette und die maximale Baumtiefe. Während der Erstellung eines eigenen Baums kann man die dabei entstehenden Werte per document.writeln ausgeben.

Eine letzte Optimierung betrifft den IE4+, der es mit dem document.all schafft, HTML-Text mehrzeilig zu ändern. Damit ist es nun möglich, ohne Neuladen der Seite den Baum zu ändern; damit sieht es schon fast perfekt aus. (Vor allem entfallen störende Scroll-Effekte.) Der Einfachheit halber wird der ganze Baum neu gezeichnet.


haftmann#software, 08/01