Diese Seite ist ein Sammelsurium alter Inhalte, die man mal etnrümpeln und gegebenefalls in verschiedene Dateien aufsplitten sollte (sofern die Inhalte noch relevant sind). — Günter 2008-04-03

Dokumentation der Entwicklung

Diese Seite ist für Erläuterungen, Beispiele und Musterdateien zu den ROOTS-spezifischen XML-Tags. Hier sollten Achraf's XML-Schema-Definitionen dokumentiert werden incl. link auf aktuelle Version der Definitionsdatei (roots.xsd) … alles noch zu ergänzen …

  • link auf beispiele von achraf auf netzspannung.org: …

absatz_vorlesung

bietet eine feste menge von relevanten einträgen zu vorlesungen, die in einer festen reihenfolge angezeigt werden.

einträge, zu denen keine inhalt eingegeben wird, werden nicht angezeigt.

man kann als erweiterung des inhalts eines eintrages weitere, selbstdefinierte zeilen in die veransstaltungstabelle eintragen.

  • [absatz_vorlesung.doc|Wie man damit in Authentic arbeitet]
  • Wer lieber auf Text-Ebene arbeitet findet eine entsprechende Musterdatei auf der obersten Ebene des /teaching-Ordners (…/roots.iai/teaching/musterLehrveranstaltung.xml). Darin ist auch ein Beispiel eines “selfdefined” Entrages.

Navigationsstruktur


Logisch

  • Search-Maske oben rechts im Header
  • Hauptnavigationsleiste an unterer Kante des Headers:
    • Research (links ausgerichtet)
    • People (links ausgerichtet)
    • Teaching (links ausgerichtet)
    • Services (links ausgerichtet)
    • Home (rechts ausgerichtet)
    • Sitemap (rechts ausgerichtet)
    • Contact (rechts ausgerichtet)
  • Path am oberen Rand einer jeden “Body”-Seite (←- noch nicht umgesetzt)
    • Gibt den Pfad in dem Navigationsbaum an, an dem man sich gerade befindet (als Links auf “Oberseiten”)
  • Bereichsspezifische Navigation am linken Rand jeder Seite (ausser der Einstiegsseite):
    • Bereichsspezifisch, je nach Auswahl in Hauptnavigationsleiste. Sie setzen sich evtl. zusammen aus Unterbereichen, die projektspezifisch (oder lehrveranstaltungsspezifisch) definiert werden können.
  • News-Bereich unter der bereichsspezifischen Navigationsleiste
    • Automatisch generiert aus News-Einträgen der Unterbereiche. Nur N aktuellste Meldungen werden gezeigt (oder gar nichts, wenn es keine gibt).

Umsetzung mittels Cocoon-Sitemaps

Sitemaps erledigen die Abbildung von URLs auf Inhalte, wobei evtl. dynamische Transformationen angewendet werden. Sie können directory-spezifisch definiert werden. Unterdirectories können die Mappings allgemeiner Directories redefinieren (overriding). Aktuell verwenden wir jedoch nur 2 sitemaps (auf der obersten Ebene der Dateihierarchie).

Die Hauptnavigationsleiste (am oberen Rand) ist fest definiert.

Die bereichsspezifische Navigatioinsleisten (am linken Rand) werden durch die menu.xml-Dateien inkrementell definiert, so dass die Inhalte der menu.xml-Dateien von Unter-Ordnern als Unter-menues integriert werden. Die projektspezifische (bzw. lehrveranstaltungsspezifische) Navigation wird von den am Projekt / an der LV beteiligten in lokalen Unter-Sitemaps definiert.

–> [Genaue Doku der Navigations-Umsetzung mit Cocoon|Cocoon Struktur]

Umgesetzte Vorschläge


PAPER SEITEN der Projekte * Haben nun Heading und einen passenden Title * Jede Publikation hat nun nun ref auf bibtex-Entry und download.

LINKES MENU

* Nun bis zu 3 Schachtelungsebenen möglich

NEWS

* Eine news-Datei pro Ordner und eine globale * Projekt-News: Die News-Seite des Projekts wird als rechte Spalte in die sonstigen Projektseiten eingeblendet, sofern es news gibt, die neuer als 2 Monate sind. Bereichs-News: Aus den News Seiten der Projekte, Lehrveranstaltungen, Events, … werden alle News die neuer sind als 1 Monat aggregiert als rechte Spalte der top-level-seite dieses Bereichs dargestellt. * Roots-News: Die aus der globalen News-Seite und denen der Projekte (incl. Lehrveranstaltungen) werden alle News die neuer sind als 2 Wochen aggregiert als rechte Spalte der top-level-seite dargestellt.

HISTORY

Aus der news.xml-Datei in einem Projektordner werden alle Einträge im News-Format aufbereitet als (nicht physikalisch vorhandene) Datei “History” zur Verfügung gestellt. Mann kann somit eine komplette News-History für ein Projekt (top-level-ordner) anbieten, indem man in die Datei “menu.xml” folgenden Eintrag einfügt.

	<menu-entry link="history">
	  <name>History</name>
	</menu-entry>

*Empfehlung: Als vorletzter Link, vor “Contact”-Link. * Beispiel: Siehe [http://roots.iai.uni-bonn.de/research/jmangler/history]

SEITENINHALTE

SEITENINHALTE: SEITEN-TITEL

* Die erzeugten html Seiten haben nun ein passendes <title> Tag, damit der Fenstertitel im Browser den Inhalt der angezeigten Seite widerspiegelt.

SEITENINHALTE: ÜBERSCHRIFTEN * Ws gibt die Überschriften-Tags h1 bis h4, sowie s2 und s1. Letztere als geschachtelte Tags im Absatz_Einzug. * H2 wird als balken formatiert

SEITENINHALTE: INHALTSVERZEICHNIS

Jede einzelne Überschrift H1,H2,H3,S1,S2 hat ein Attribut “Inhalverzeichnis”. Der Default-Wert ist “true”.

Jedes seite-Tag verfügt über die Attribute inhv_h1, inhv_h2 inhv_h3, inhv_s1, inhv_s2. default für dise attributen ist \”false\”.

für jedes der attribute inhv_h1, inhv_h2 inhv_h3, inhv_s1, inhv_s2, das den wert true hat (z.b. inhv_h2_true) werden alle Überschriften der entsprechenden ebene deren \”inhaltsverzeichnis\”-attribut nicht auf false gesetzt ist, in das Inhaltsverzeichnis übernommen, das hinter der Seitenüberschrift eingefügt wird.

(dsp, Nur als Vorschlag!! Will keine zusätzliche Arbeit erzeugen:) Da die Attribute für “h1”, “s1” eine andere Bedeutung haben, als für “seite”, sollte es wohl auch anders heißen. Wie wäre es mit “exclude_from_inh_verz” oder “hide_in_inh_verz”

SEITENINHALTE: AUFZÄHLUNGEN

Das Element “aufzaelung” ist jetzt innerhalb eines Elementes “liste” verwendbar. Für eine nummerierte Aufzählung muss man bei dem “aufzaehlung” Element das Attribut “type” auf “num” setzen.

Die Elemente “Aufzählunh_level_2” und “Aufzählung_level_3” existieren nicht mehr. “Liste” kann stattdessen rekursiv benutzt werden, um verschachtelte Aufzählungen zu erzeugen.

SEITENINHALTE: LINKS

* Externe Links werden automatisch erkannt (das setzen der intern und extern attribute ist somit “deprecated”). * Externe Links werden durch einen kleinen roten Pfeil angezeigt, wie auch im Wiki. * Broken links werden durch graue Schrift angezeigt.

SEITENINHALTE: VERSCHIEDENES

* ERLEDIGT (–> ab): code wird im laufenden Text ausgezeichnet (was muss man dafür eingeben?). * ERLEDIGT (–> ab): featuretag heisst jetzt futuretag.

ToDo


Inhalte

Research/ACE

\\Iaiw2khome\rootsweb\roots.iai\research\ace\publications.xml konsistent machen mit \\Iaiw2khome\rootsweb\roots.iai\research\ace\ace.bib

XML Infrastruktur

Generierung von news-Einträgen

* Fehler: nach Aktualisierung des News-Eintrags für JMangler wurde die neue Version nur im research-bereich angezeigt, aber nicht auf der top-level-seite.

Generierung von bibtex-Einzel-Einträgen zu Publikationen

Auf misteriöse Weise verschwindet aus den URL-Angaben in publications.xml-Dateien jeweils das “download” directory: in den automatisch generierten bibtex-EINZEL-Einträgen ist es nicht mehr enthalten. (Die gemeinsame Datei aller bibtex-einträge, ist hingegen korrekt).

Siehe als Beispiel:

http://roots.iai.uni-bonn.de/research/ace/publications

http://roots.iai.uni-bonn.de/research/ace/bibtex/publications.bib
  url = {http://roots.iai.uni-bonn.de/research/ace/downloads/kniesel96_encapsulation.pdf},
                                                  ^^^^^^^^^^^
http://roots.iai.uni-bonn.de/research/ace/bibtex/kniesel96_encapsulation.bib
  url = {http://roots.iai.uni-bonn.de/research/ace/kniesel96_encapsulation.pdf},
                                                  ^

Tabellenlayout

* default linksbündig * Kann man das jetzige Tabellenlayout mit im Druck sichtbaren Rändern versehen?

Gesamtlayout

* Wenn Uni-CorporateDesign fertig, Logos und Farben (Schrift, Balken, Menues, …) an Uni-Bonn-Blau anpassen * Siehe Zentrale CD-Info-Webseiten: [http://www.uni-bonn.de/Aktuelles/CD.html] (nur aus Uni-Netz- zu erreichen!) * Uni-Bonn-Logo und Informatik III Logo integrieren, siehe Beispiel [file:/W:/gk/data/web/rootsMitUniLogo/roots.iai.uni-bonn.de.htm] ===== Fragen und Wünsche zur Technik unserer Website ===== ==== Konventionen ==== * (dsp, hm, rb, ck, gk ab): Da, wo wir gleiche Unterpunkte im Menü verwenden sollten wir auch die gleiche Reihenfolge einhalten. (Nein, ich will keine beengenden Standards erzwingen. Ich denke nur, das hilft einem Besucher, sich schnell zu orientieren.) ==== Vorschläge –> Workarounds ==== * (hm): ImageMaps fehlen mir sehr.\\(ab): Links auf Bildern sind keine Problem. Wird gemacht. ANSONSTEN: Man kann die Image Map in einer XHTML-Seite unterbringen (und dabei alle Tools zu Generierung von Image maps nutzen) und von da aus auf XML-Dateien verweisen. ==== Vorschläge –> In Arbeit ==== Mit Zuordnung wer zuständig ist. Wenn Erledigt, bitte nach “Vorschläge –> Fertig” verschieben ==== Neue Vorschläge und Wünsche (noch nicht vom Webteam besprochen) ==== === SEITENINHALTE: ÜBERSCHRIFTEN === * Man könnte die Anker aus den Überschriften automatisch generieren (z.B. #Variable_annotation_ _mandatory_ oder #VariableAnnotationMandatory oder #Variableannotationmandatory) oder aus der Struktur (z.B. #h1_1_s1_3). Wobei die erstgenannte Version des Ankers dauerhafter wäre. * Wenn die Anker NICHT automatisch generiert werden und daher Überschriften im Menü auftauchen, die nicht verlinkt sind (das könnte sogar ein Feature sein!), so sollten diese nur als Text und nicht als Link erscheinen. * (Der Kunde hat Blut geleckt! Gierig entwickelt er neue Wünsche:) Man könnte tatsächlich aus dem vorhergehenden Punkt ein Feature machen: Statt “true” und “false” könnte man als Wertebereich für die Attribute “no”, “text”, “link” bzw. im laufenden Text “default”, “no”, “text”, “link” angeben. Wobei “text” halt Auflisten der Überschrift und “link” zusätzliche Verlinkung bedeutet. “default” ist natürlich default und bedeutet, dass die Einstellungen der “seite” gelten. === Contents === * (hm) Auf jeder Seite einen Mailto-Link für Feedback und Fragen (stets an der gleichen Position auf der Seite). Das könnte sich zB für die Personenseite an gk@… für die contract-Seiten an dsp@… und für die PatchWork-Seiten an muegge@… richten. * (gk) “Events”-Rubrik mit Verweisen auf die von uns veranstalteten Events (Workshops, tagungen, Schulungen, etc, …) * (gk) Evtl. das News-Format nutzen um für uns relevante “upcoming events” zu sammeln und automatisch, nach dem Datum der “deadline” aufsteigend sortiert zu aggregieren, events mit mehr als 2 Wochen vergangener Deadline nicht mehr anzuzeigen, kurz bevorstehende Dedlines hervorheben, etc. … ==== Fehler ==== * (dsp): Anker, die man für einen Absatz definiert, werden durch das XSLT wieder herausgefiltert (oder nicht erzeugt). ==== Fragen ==== * F: (hm) Was macht das <s2> Tag, das man z.B. in <absatz_einzug> verwenden darf? Inhalt von <s2> wird nicht angezeigt. ===== Updates Einspielen ===== Folgendes sind angedachte Möglichkeiten, leider ist noch nichts umgesetzt. ==== 1. Direkt auf Server arbeiten==== [[Rachid:] Ich denke, dass es in Zukunft eher unwahrscheinlich ist, dass wir gleichzeitig auf den Dateien arbeiten werden und denke daher, dass wir kein CVS benötigen werden. Wir sollten uns nur daran gewöhnen, direkt auf den (aktuellen) Original-Dateien zu arbeiten. Damit könnten wir die meisten Probleme lösen. Das ganze Web-Team arbeitet direkt auf den Dateien der Site, anstatt auf den eigenen lokalen Dateien. Das heisst, wer zu Hause was ändern will, muss direkt auf gollum zugreifen (über VPN), anstatt auf evtl. veralteten lokalen Kopien zu arbeiten. Mit VPN erhält man eine interne IP des Institutes und kann sich dann einen Samba-Mount direkt auf gollum unter Windows einrichten, so dass man unter Windows komfortabel direkt auf den Original-Dateien arbeiten kann. Dafür müsste Achraf einen VPN-Account im Institut beantragen. Dann kann er auch zu hause auf den Original-Dateien (und somit den aktuellsten Dateien) arbeiten und die neuen XSTLs, etc selbst einspielen, anstatt uns die Dateien zu schicken. ==== 2. Teilweise Versionskontrolle ==== Nur Teile des Ganzen unter Versionskontrolle zu stellen (typischerweise die Dinge, für die wir das Web-Team zuständig ist - also XSLT, schemata, …). Bei nur 3-4 Leuten ist es sicher nicht so schwer, die disziplinierte Nutzung von subversion oder ähnlichem durchzusetzen. Schliesslich hat ja auch jeder unmittelbar was davon. ←- Dies ist die Option, die ich langfristig bevorzugen würde – GK ==== 3. Alles Versionieren ==== Scheint mir zur Zeit nicht wirklich sinnvoll (ausserhalb der kritischen Infrastruktur - XSLT, CSS, …) – GK

Last modified: 2014/04/11 02:49
 
*