FrontierWeb.de

Websites bauen mit Frontier, Teil 3

Nachdem wir in den ersten beiden Teilen unseres kleinen Frontier-Tutorials gelernt haben, wie man eine Webseite in Frontier erstellt, werden wir nun unsere kleine Website um weitere Seiten ergänzen. Dabei lernen wir auch den Wiki-ähnlichen Link-Mechanismus von Frontier kennen und ich werde zeigen, wie Frontier einen hilft, Navigationsleisten zu erstellen und zu verwalten.

Nahezu jede Website braucht heutzutage ein Impressum, daher werden wir als erstes auch eines anlegen. In der gleichen Tabelle, in der auch unsere index liegt, legen wir einen neuen WP-Text an, den wir impressum nennen. Außerdem ziehen wir uns nebenstehendes Bild (m)eines Hundes runter und laden ihn wie gewohnt in die #image-Tabelle (wenn Ihr nichts geändert habt, heißt das Bild dann hund01). Und jetzt tippen wir folgenden Text in das Textfenster (ein paar Zeilenumbrüche habe ich künstlich erzeugt, damit der Text lesbar bleibt, notwendig sind sie nicht):

Das ist — glaube ich — nicht gerade ein gesetzlich konformes Impressum, aber es dient ja auch nur als Beispiel. Wenn wir die Seite nun rendern, erhalten wir folgendes Bild:

Erst einmal scheint alles wie gewohnt. Erwartungsgemäß hat Frontier unser Template genommen und es mit dem Text der Impressums-Seite zusammengefügt. Doch halt, da unten, wo wir "Startseite" geschrieben haben, dort ist ein Link. Und wenn wir auf ihn klicken, gelangen wir tatsächlich zurück zur Startseite. Was ist dort geschehen?

Der »Glossary«-Mechanismus

Frontier verfügt in der Tat über einen Wiki-ähnlichen Mechansimus der Link-Substitution. Für jede Seite, die wir mit Hilfe von Frontier anlegen, legt es in einer Subtable (#glossary) der Datenbank einen Eintrag an, der den Title und den Pfad (die URL) die zu der Seite führt, enthält. Wenn Frontier nun auf eine Textstelle stößt, die in Hochkommata ("") eingeschlossen ist, überprüft es in seiner Datenbank, ob dafür ein Eintrag vorhanden ist und wenn ja, ersetzt dies durch den dazugehörenden Link. Und nicht nur das: Wir können auch eigene Einträge in die i>#glossary-Tabelle vornehmen und damit nicht nur links, sondern auch Shortcuts, also Kürzel für immer wiederkehrende kurze HTML-Schnipsel erzeugen. Beispiele dafür (über 600 Kürzel) finden sich in der Frontier.root in der Tabelle user.html.glossary. Diese Tabelle wird übrigens immer auch noch durchsucht, wenn Frontier auf die Hochkommata stößt. Das ist einerseits nützlich, weil dort viele sinnvolle Abkürzungen eingetragen sind, andererseits aber manchmal auch gefährlich. Probiert einmal aus, was passiert, wenn Ihr in einem Text »Der Truthahn wird auf englisch "turkey" genannt« eingebt und dieses dann rendert. . Wenn man nicht will, daß Frontier das Hochkomma auswertet, muß man es »escapen«, das heißt einen Backslash (\) davorsetzen. Wißt Ihr nun, warum ich auf die französischen Anführungszeichen (»«) gekommen bin?

Wie dem auch sei, der glossary-Mechanismus ist extrem nützlich und erspart einem viel Arbeit. Doch was ist, wenn ich zwar auf die Startseite zurückwill, im Text aber aus unerklärlichen Gründen »Heimatseite« schreiben will. Dafür bietet Frontier ein Makro, glossSub() (für glossary substitution) genannt. Wenn wir also schreiben

Zurück zur {glossSub(Startseite, "Heimatseite")}

dann ersetzt Frontier »Startseite« durch »Heimatseite«, baut aber den darunterliegenden Link auf die Startseite korrekt.

Verzeichnisse oder Directories

Größere Websites — und Frontier ist durchaus in der Lage, auch sehr große Websites zu verwalten — liegen natürlich nicht flach in einem Verzeichnis (oder Directory), sondern sind — hoffentlich — über ihre Verzeichnisstruktur sinnvoll gegliedert. Auch Frontier kann damit natürlich umgehen, eine (Sub-) Tabelle wird zu einem Verzeichnis gerendert. Darüberhinaus bieten Untertabellen auch nch ein paar weitere Vorteile, die wir jetzt erkunden wollen. Dafür legen wir erst einmal in unser Hauptverzeichnis (das ist das Verzeichnis, in dem unsere »Startseite« liegt, erst einmal eine Untertabelle an und nennen Sie termine. Die Datenbank sollte jetzt wie folgt aussehen:

Innerhalb dieser Tabelle legen wir jetzt ebenfalls eine Datei namens index an, aber nicht als WP-Text, sondern als Outline! Und dieses Outline füttern wir wie folgt:

Wenn wir dieses Outline wie gewohnt rendern (was die zweite Zeile bedeutet und warum überhaupt ein Outline, das erzähle ich weiter unten), dann erhalten wir folgende Webseite:

Wie wir sehen, hat Frontier die Präferenzen von der darüberliegenden Tabelle übernommen. Und das ist eine der großen Eigenschaften (die Frontier übrigens mit Zope teilt), die Frontier so flexibel machen: Tabellen »erben« die Eigenschaften darüberliegender Tabellen, sofern in dieser Tabelle nichts anderes definiert ist. Wir können ja einmal spaßeshalber in dieser Tabelle eine eigene Direktive definieren, indem wir dort z.B. eine eigene #prefs-Tabelle anlegen und in dieser eintragen:

bgcolor: ffffff

Wenn wir jetzt unsere Terminseite neu rendern, hat diese einen weißen Hintergrund, alle anderen Einstellungen werden weiterhin von der darüberliegenden Tabelle übernommen.

[Doch Vorsicht]: Nicht alle Direktiven sind so liberal, wie die in der #prefs-Tabelle. Fast alle anderen #xxxx-Tabellen »konsumieren«. Wenn wir z.B. in einer Untertabelle eine #tools-Tabelle haben und Frontier dort eine Direktive oder ein Makro nicht findet, dann findet es diese Direktive oder dieses Makro auch nicht in einer darüberliegenden #tools-Tabelle. Hier sagt sich Frontier: #tools habe ich abgearbeitet und damit ist die Sache für mich erledigt, weitere #tools-Tabellen interessieren mich nicht. Das ist von Frontiers Standpunkt aus logisch (genauso, wie es sinnvoll ist, daß die #prefs- (oder #images) Tabelle hier eine Sonderstellung einnimmt und eben nicht »konsumiert« wird), aber für viele Menschen eine Quelle schwer zu findender Bugs. Daher sammele ich, wenn ich nicht ganz etwas Seltsames vorhabe (und — hoffentlich — genau weiß, was ich tue), alles, was in die #tools-Tabelle gehört, in einer Tabelle im Wurzelverzeichnis meiner Website.

Für jede Tabelle legt Frontier ein eigenes Verzeichnis an, wobei Tabellen in Tabellen Verzeichnissen in Verzeichnissen entsprechen. (Daher spreche ich hier in diesem Tutorial auch immer synonym entweder von Tabellen oder Verzeichnissen.) Dies — zusammen mit dem Vererbungsmechanismus — erlaubt es uns, wenn gewünscht, für jedes Verzeichnis ein eigenes Layout festzulegen. Wir wollen dies im Moment jedoch nicht und daher löschen wir die #prefs-Tabelle im Verzeichnis termine einfach wieder.

Outline-Renderer

Doch warum haben wir die Termine nicht in einem WP-Text, sondern in einem Outline angelegt? Zum einen, weil ich Outlines liebe und auch diesen Text hier in Frontiers Outliner schreibe, zum anderen, weil Frontier Outline-Renderer kennt, die es noch einmal einfacherer machen, Texte für das Web zu erstellen. Wir benutzen hier einen einfachen, mitgelieferten Outline-Renderer namens fatHadlines, der im Prinzip den ersten Level eines Outlines fett ausgibt und alle anderen darunterliegenden Level als einfache Paragraphen. Dieser Renderer ist nicht perfekt (vor allem ist er nicht XHTML-fest), aber für den Anfang zeigt er uns erst einmal, wie so ein Outline-Renderer funktioniert. Frontier liefert noch etliche andere Outline-Renderer mit, aber es ist auch nicht schwer, sich in UserTalk seinen eigenen Outline-Renderer zu schreiben. Wir werden im Laufe dieses Kurses darauf noch zurückkommen. Welchen Outline-Renderer wir verwenden wollen, teilen wir Frontier ebenfalls mit einer Direktive (#renderOutlineWith) mit. Diese kann im Outline selber stehen, dann gilt sie nur für dieses eine Outline, aber sie kann auch in der #prefs-Tabelle stehen und dann werden alle betreffenden Outlines damit »verarztet«.

Unsere letzte Seite

Last, but not least legen wir in unserem Wurzelverzeichnis eine weitere Tabelle an, die wir nachrichten nennen. In dieser Untertabelle legen wir schon einmal prophylaktisch eine weitere Untertabelle an, die wir wieder #images nennen und natürlich wieder eine Outline, die wieder index heißt.

Dann laden wir obenstehendes Bild (wenn Ihr nichts verändert habt, heißt es dsc_mannschaft_01446) in unsere frisch angelegte #images-Tabelle. Und in unsere neue index-Datei schreiben wir Folgendes:

Wenn wir dies wiederum rendern, erhalten wir folgende Website:

Was ist hier neu? Eigentlich nur, daß auch die #images-Tabelle (aus gutem Grund) zu den (Sub-) Tabellen gehört, die alle durch die gesamte Hierarchie hindurch durchsucht werden. Das erlaubt es uns, Bilder in die Nähe der anzulegenden Webseiten abzulegen und wir müssen sie nicht in einem Monsterverzeichnis sammeln.

Das Navbar-Makro

Zu jedem Content-Management-System gehört die Möglichkeit, die üblichen Navigationsmechanismen komfortabel und weitstgehend automatisch zu erstellen. Frontier bietet hier — neben der Möglichkeit, eigene Routinen in UserTalk zu erstellen — das navBar()-Makro. Um das zu realisieren erstellen wir erst einmal in der obersten #prefs-Tabelle eine neue Outline, die wir myLinks (der Name ist frei wählbar) nennen:

Und dann tauschen wir in unserem Template folgende Zeile

<td bgcolor="#99cc99">Startseite | Nachrichten | Termine | Impressum</td>

gegen

<td bgcolor="#99cc99">{navbar("myLinks", "horizontal", boldCurrentPage:true)}</td>