udrec_suite

Dokumentation mit UDO

27. April 2004

von
Wolfgang Wershofen


1 Einleitung

In diesem Dokument geht es um die Handhabung der udrec-Dokumentation und die Pflege der Webseiten mit UDO. Kai hatte dieses Tool Ende 2003 aufgetan und es eignet ich hervorragend, um erstens das Design der Website von deren Inhalt zu trennen und zweitens die Dokumentation aus einer Quelle in verschiedene Zielformate umzuwandeln. Dadurch erspart man sich eine Menge Doppelpflege und vor allem könnt auch ihr Nicht-HTMLer ganz bequem kleinere Updates an der Website durchführen.

Um Euch diese Arbeit so einfach wie möglich zu machen, habe ich diese Doku erstellt, in der ich Euch das Konzept der UDO-Sourcen und wie man daraus welches Zielformat erstellt, erläutern möchte.

Viel Spaß dabei. Bei Fragen, schickt mir eine Mail. ;-)

cu
Wolle

P.S.: Übrigens, dieses Dokument habe ich auch mit UDO erzeugt. :)


2 UDO-Sourcen

Ich möchte hier eigentlich nicht näher auf die UDO-Syntax bzw. den generellen Aufbau von UDO- Dokumenten eingehen. Dazu gibt es ziemlich ausführliche Informationen unter http://www.udo-open-source.org. Hier soll es mehr darum gehen, wie ich die UDO-Sourcen speziell für unsere udrec_suite angelegt habe und wie man wo was findet.


2.1 Namenskonventionen

In den UDO-Sourcefiles der udrec_suite gibt es z.Zt. drei verschiedene Dateitypen, die ich durch unterschiedliche Extensions kenntlich gemacht habe.

*.udo:
Das sind die eigentlichen Sourcefiles. Für jedes Dokument (HTML-Seite,Manpage,README) gibt es ein *.udo File, aus dem die entsprechende Seite erzeugt wird. Im Wesentlichen bestehen diese Dateien aus eine Reihe von !include-Statements
*.ui:
Hier finden sich die tatsächlichen Texte und Inhalte wieder. Diese Dateien werden in den *.udo Dateien mit !include eingebunden und können so zu verschiedenen Dokumenten/Layouts zusammengestellt werden.
*.htm:
In diesen wenigen Dateien ist reiner HTML-Sourcecode enthalten, um z.B. den Header der Website mit den Logos und die Fußzeile auszugeben. Die HTML-Fähigkeiten von UDO sind ein wenig begrenzt, daher bietet sich die Einbindung von nativem HTML an Stellen, die mit UDO nicht zu bewerkstelligen sind, an.

Bei den eigentlichen Dateinamen habe ich auch versucht, mich an einige Konventionen zu halten. Die Dateinamen fangen immer mit dem hauptsächlichen Einsatzgebiet an, für den die jeweilige Datei gedacht ist. z.Zt. sind das:

website_*:
Inhalte, die hauptsächlich für die Website gebraucht bzw. benutzt werden
man_*:
Inhalte, die hauptsächlich für die manpages gebraucht werden
readme_*:
Inhalte, die hauptsächlich für die readme-Files gedacht sind
shared_*:
Inhalte, die für alle Zielformate benutzt werden

Natürlich läßt sich durch die Tatsache, daß die meisten Textinhalte in allen Zielformaten Verwendung finden, trefflich drüber streiten, ob eine Datei nun eher für die Webseite oder für das readme gemacht wurde, aber das bringt wohl nicht viel. Vielmehr sollte man sich einmal für einen Prefix entscheiden und diesen dann beibehalten, da eine Änderung des Dateinamens mit viel Aufwand verbunden ist, wenn dieser schon in einigen anderen Files verwendet wird.

2.2 Verzeichnis-Struktur

Neben dem Ziel, eine Quelle für alle Dokumentationen zu haben, bietet UDO auch eine prima Gelegenheit, Design und Inhalt voneinander zu trennen. Da ich unsere bestehende Website durch den Einsatz von UDO nicht komplett umgestalten wollte, sondern das Layout unverändert erhalten bleiben sollte, mußte ich ein paar Kunstgriffe einbauen, die eine 1:1-Portierung einer Quelle in alle Zielformate zwar nicht unbedingt unmöglich, aber doch nicht besonders empfehlenswert macht. Um dennoch so wenig Redundanz wie möglich zu gewährleisten, sind die UDO-Sourcen sehr modular aufgebaut, wodurch sich zwangsläufig zwar die Anzahl der zu pflegenden Dateien erhöht, allerdings sind diese dann wiederum so klein, daß sie sehr einfach zu handhaben sind. Um in diese Dateien ein wenig Struktur zu bekommen, habe ich die Sourcen in mehrere Unterverzeichnisse verteilt und auch hier versucht, die Trennung von Design und Inhalt zu dokumentieren

./source:
In diesem Hauptverzeichnis der UDO-Sourcen sollten sich alle *.udo Files wiederfinden
./source/includes:
Hier sollten die Include-files (*.ui, *.htm) abgelegt werden
./source/includes/content:
In diesem Verzeichnis sollen alle Includes abgelegt werden, die die eigentlichen Inhalte repräsentieren, sprich, die reinen Texte - ohne Layout und Design.
./source/includes/webdesign:
Hier sind die Includes abgelegt, die speziell für das Design der Website verantwortlich sind
./source/skels:
In diesem Verzeichnis habe ich ein paar leere und dokumentierte Vorlagen abgelegt, die zur Erstellung neuer UDO-Sourcen genutzt werden können. z.Zt. sind das
shared_skel_body.ui:
Enthält die Vorlage zur Erstellung eines "Content-Includes", also einer Datei, die den Text eines Dokumentes enthält
website_skel_page.udo:
Enthält eine Vorlage zur Erstellung einer komplett neuen Seite für die Website.
website_skel_right.ui:
Enthält eine Vorlage zur Erstellung einer Kurzinfo für die rechte Spalte.
man_skel.udo:
Enthält eine Vorlage zur Erstellung einer manpage.

Soviel zu den Verzeichnissen und Namenskonventionen. Ich denke, daß der Aufbau soweit nicht weiter schwierig nachzuvollziehen ist. Grundsätzlich sollte sich das Hauptaugenmerk für Änderungen an der Dokumentation auf den Ordner ./source/includes/content konzentrieren, eventuell sind auch Anpassungen an den *.udo Files notwendig, wenn neue Inhalte hingekommen sind.


3 Zielformate

Über die drei Zielformate an sich brauche ich ja auch nicht wirklich viele Worte zu verlieren. Es soll hier eigentlich auch mehr um die eventuellen Besonderheiten und Unterschiede der einzelnen Formate gehen.


3.1 Website

Naturgemäß ist die Website das komplexeste Format. Während sich die readmes und manpages mit reinem Textlayout zufrieden geben, soll eine Website ja auch optisch ansprechend mit Bildern, Farben und Hintergründen gestaltet sein. Außerdem ist unsere Website in drei Bereiche unterteilt, die Navigationsleiste links, den Hauptteil in der Mitte sowie die rechte Spalte mit weiterführenden Kurzinformationen im Bezug auf den Hauptteil.
All das muß im Gegensatz zu den anderen Formaten für die Website definiert werden. Das meiste davon habe ich in ein paar zentrale Include-Member des Ordners Webdesign gepackt, damit der Inhalt der Seite weitestgehend vom Layout getrennt wird. Hier die wichtigsten dieser Includes:

website_page_header.htm:
Enthält in native-HTML die Definition des Seiten-Headers mit den Logos sowie die Definition der dreispaltigen Tabelle
website_page_footer.htm:
Ebenfalls native-HTML die Definition der Fußzeile unter jeder Seite
website_right_col.htm:
Hier ist der Beginn der dritten Spalte (rechte Seite) in native-HTML abgelegt, inklusive des Sourceforge-Buttons.
website_nav_col.ui:
Enthält die UDO-Source der linken Spalte mit dem Navigationsmenu. Die einzelnen Zustände des Menus, welcher Link gerade aktiv ist etc., wird über eine ifset-Abfrage auf eine Variable definiert, die in der eigentlichen UDO-Source der jeweiligen Website gesetzt werden muß. Auf diese Weise passt dieses Include-Member unverändert auf jede einzelne unserer Seiten. ;-)
website_page_start.ui:
Enthält alles, was zum Anfang einer jeden Webseite definiert und inkludiert werden muß. Somit muß lediglich dieses Include in die UDO-Definition der Webseite eingefügt werden, um das komplette Layout der Website verfügbar zu haben.

Die übrigen Member des Webdesign-Orders (website_right_*.ui) enthalten die kleinen Kurzinfos, die in der rechten Spalte angezeigt werden.

Jede einzelne Webseite hat ihr eigenes UDO-Sourcefile, weil ansonsten die Verwendung unserer Logografiken zu Beginn der Seite nicht mehr funktionieren würden. Leider funktioniert dadurch natürlich die automatische Verlinkung einzelner Abschnitte über UDO nicht mehr, dafür finde ich den somit etwas modulareren Aufbau der Sourcen etwas übersichtlicher.
Wenn man eine neue Seite für die Website anlegen möchte, muß man daher folgende Schritte durchführen:

  1. Kopieren der Vorlagedatei "source/skels/website_skel_page.udo" unter einem anderen Namen in das Verzeichnis "source". Anschließend öffnen der Datei in einem beliebigen Editor und Füllen der Platzhalter (beginnen mit "$") mit konkreten Werten
  2. Kopieren der Vorlagedatei "source/skels/shared_skel_body.ui" unter einem anderen Namen in das Verzeichnis "source/content". Hier wird anschließend der Textinhalt der neuen Seite eingegeben.
  3. Ggf. kopieren der Vorlagedatei "source/skels/website_skel_right.ui" unter einem anderen Namen in das Verzeichnis "source/webdesign", falls eine passende Kurzinfo zum Hauptteil vorhanden sein soll.
  4. Eintragen der neuen Seite als Link im Include-Member "source/includes/webdesign/website_nav_col.ui"
  5. Durchführen einer Generierung für die Website

That's it.

3.2 readme

Hier hab' ich noch nichts konkretes. Wird gefüllt, wenn ich die ersten "ernsthaften" READMEs gebaut habe.

3.3 manpages

Die manpages haben einen sehr monolithischen Aufbau, da nur sehr wenige UDO-Objekte hier sinnvoll integriert werden können. Allenfalls die generelle Programmbeschreibung könnte aus den Webseiten übernommen werden, allerdings ist das nur ein sehr geringer Teil des Umfanges der manpages.
Die Quelldateien der manpages sollten analog zu den oben genannten Namenskonventionen angelegt werden. Für die Generierung wichtig ist die Angabe des UDO-Befehls !man_type, in dem die Nummer des manpage-Abschnittes angegeben wird (1 für Programmbeschreibungen, 5 für Dateibeschreibungen etc - siehe "man man" für eine komplette Liste.
Für die Neugenerierung einer manpage gibt es ein Skeleton mit den gebräuchlichsten manpage-Einteilungen (siehe Verzeichnis-Struktur).
Die erzeugten manpages werden übrigens bei der Generierung der Website mit dem Script build_website in HTML-Seiten umgewandelt und sind anschließend auch online abrufbar. Zur Generierung dieser Seiten wird das Tool man2html verwendet.


4 Generierung

Um nun aus den UDO-Source die fertige Dokumentation zu erzeugen, muß eine entsprechende Generierung durchgeführt werden. Bei der doch etwas umfangreicheren Anzahl an Webseiten, readme und manpages sollte diese Generierung weitestgehend automatisiert ablaufen. Hierzu habe ich einige Scripte erstellt, die die Generierung für die jeweiligen Zielformate übernehmen.

Die Scripte liegen im Verzeichnis "doc" und sind auch nur lauffähig, wenn sie von dort aus aufgerufen werden, da einige relative Pfadangaben darin enthalten sind. Benötigt werden die Tools UDO und man2html um die Generierung durchführen zu können
Eine Generierung erfolgt nur dann, wenn mindestens eine der UDO-Quelldateien neueren Datums ist als die zu generierende Zieldatei. Geprüft wird die mit dem Script checkUDOsrc.


4.1 Scripte

Folgende Scripte sind aktuell schon vorhanden:


4.1.1 checkUDOsrc

Mit diesem Script wird geprüft, ob mindestens eine zur Erzeugung einer Zieldatei benötigte UDO-Quelldatei neuer ist als die zu generierende Seite. Die Syntax des Scripts sieht so aus:

    checkUDOsrc <quelldatei> <zieldatei>

Das Script prüft zunächst, ob die <quelldatei> neuer ist als die <zieldatei>. Ist dies nicht der Fall wird in der <quelldatei> nach Includes gesucht und fr jedes gefundene Include ruft sich das Script selbst wieder rekursiv auf. Sobald eine neuere <quelldatei> gefunden wird, beendet sich das Script mit RC 1 und gibt den Namen der gefundenen Datei über /dev/stdout aus. Wird keine neuere Datei gefunden, endet das Script mit RC 0.

4.1.2 build_website

Der Name ist Programm. Mit diesem Script wird die gesamte udrec_suite Website generiert. Neben dem Aufruf von udo für jede einzelne Seite übernimmt das Script noch einige Spezialaufgaben

  1. Aus den Nachrichten des Include-Members "source/include/contents/website_news_body.ui" werden die drei aktuellsten Nachrichten-Headlines extrahiert und als neues Include-File unter "source/include/webdesign/website_right_news.ui" abgelegt. Diese Datei wird in der Startseite unserer Website [source/website_index.udo -> index.html] in der rechten Spalte dargestellt. Eine manuelle Doppelpflege der News-Seite und der Headlines auf der Index-Seite ist somit nicht mehr nötig
  2. Für die dvdwizard-Scripte wird pro Script einmal der Output des Scriptes mit "-h" (Kurzreferenz) in Include-Dateien "source/include/content/man_<script>_short.ui" geschrieben. Diese Includes werden in der dvdwizard-Dokumentations-Seite in der Website verwendet.
  3. Die zuvor mit dem Script build_manpages erzeugten manpages werden mittels man2html in HTML-Format umgewandelt und ein Includemember "source/include/webdesign/website_right-man.ui" angelegt, welches alle erzeugten man-HTML-Seiten in einer Linkliste zur Verfügung stellt. Dieses Include-Member wird aktuell in die Seite doku_dvdwizard.html eingebunden.

4.1.3 build_manpage

Auch hier ist die Bedeutung des Scripts relativ selbsterklärend. Aus den UDO-Sourcen man_*.udo werden die entsprechenden Manpages im Verzeichnis "man" erzeugt. Die Generierung erfolgt auch hier nur, wenn die Quelldateien neuer sind als die Zieldatei, ebenfalls wieder gesteuert über checkUDOsrc.

4.2 Mini-HowTo: Aktualisierung der Website

Wenn Ihr Änderungen an den Webseiten vornehmen oder neue Webseiten bzw. Verweise auf manpages einfügen wollt, solltet Ihr die unten beschriebenen Schritte durchführen. Ich gehe bei diesem Quick-and-Dirty HowTo davon aus, daß Ihr den cvs-Tree der udrec_suite lokal und in aktuellem Zustand auf Eurem Rechner vorliegen habt und die CVSROOT-Variable korrekt gesetzt ist (zur Sicherheit nochmal ein "cvs update" ausführen ;-). In diesem lokalen cvs-Tree nehmt Ihr dann die Änderungen vor.

Wenn Ihr die Änderungen an den UDO-Sourcen (Verzeichnis udrec_suite/doc/source) fertiggestellt habt, dann geht Ihr folgendermaßen vor, um die Änderungen auch auf die Website zu transportieren:

  1. #> cd udrec_suite/doc
    Für die nachfolgend aufzurufenden Scripte ist es notwendig im Verzeichnis "doc" des udrec_suite Trees zu sein. Die Scripte laufen nur von dort aus korrekt.
  2. #> ./build_manpages
    Hiermit werden die manpages im Verzeichnis udrecsuite/man aktualisiert, falls es daran Änderungen gegeben hat. Dieser Schritt kann übersprungen werden, wenn die manpage-Source nicht angefaßt worden sind.
  3. #> ./build_website
    Wie schon zuvor beschrieben werden damit die HTML-Seiten der udrec_suite Website neu generiert, sofern sich deren UDO-Sourcefiles verändert haben. Das Ergebnis befindet sich dann im Verzeichnis html/htdocs des udrec_suite Verzeichnisbaums.
  4. #> cd ..
    "doc" Verzeichnis verlassen und in's udrec_suite Stammverzeichnis wechseln
  5. #> cvs commit
    Änderungen der lokalen Kopie in das cvs-Repository auf Sourceforge übernehmen. Wenn Ihr neue Objekte erzeugt habt, muß natürlich vorher noch ein "cvs add <neue_dateien>" durchgeführt werden, aber wem sag' ich das. ;-)
  6. #> ssh <userid>@shell.sf.net
    Damit macht Ihr eine ssh-Verbindung zu Sourceforge auf, in der dann das Update auf die Website durchgeführt wird.
  7. #> /home/groups/u/ud/udrecsuite/sbin/updsite
    Mit diesem Script macht Ihr dann einen cvs export auf das html/htdocs Verzeichnis im cvs repository. Der Export wird in das Verzeichnis /home/groups/u/ud/udrecsuite/htdocs/v04 gestellt und überschreibt den alten Stand dieses Verzeichnisses (besser gesagt: das Verzeichnis wird zuerst gelöscht und von cvs export neu angelegt).

That's it. Wenn das SF-CVS keine Probleme macht und wirklich die aktuellen Stände zur Verfügung stellt, können die Änderungen jetzt unter http://udrecsuite.sf.net/v04 kontrolliert werden.


5 Einbindung in CVS

Hier bin ich mir noch nicht so ganz schlüssig, wie diese ganze Sache in's CVS eingebunden werden soll. Ein Außenstehender, der sich die udrec_suite aus dem CVS holt, soll ja nicht den gesamten Sourcecode der Website oder noch besser die UDO-Sourcen erhalten, weil ihn das vermutlich nicht die Bohne interessiert. Hier muß Kai mir mal helfen.