Aber bevor ich in einen Rausch von Anschuldigungen, Verfluchungen und verzweifelten Rundumschlägen verfalle – eine kurze Vorstellung von dem was agile Softwareentwicklung leisten soll.
Wikipedia beschreibt die Zielsetzung von agiler Softwareentwicklung wie folgt:

Das Ziel Agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die Agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen wie dem Rational Unified Process oder dem V-Modell.

Häufig wird sich vor allem auf die ersten beiden Sätze konzentriert, die selbstverständlich eine große Bedeutung haben. Aber aus meiner Sicht hat aber der letzte Satz eine interessante Nebenbedeutung.
Im Folgenden werde ich mich auf die Vorgehensweise nach Scrum konzentrieren, da sie meist als Vorzeige-Prozess verwendet wird und sich viele Firmen dies auf die “Fahnen” schreiben.
Agile Softwarentwicklung wird als Gegenbewegung zu bürokratischen Prozessen angesehen. Was hier nur häufig scheinbar hinzugefügt wird, ist das Abschaffen von (notwendigen) formalen Regeln.

• So ignoriert man des öfteren, dass ein Sprint in sich unveränderbar ist – das dies auch legitim sein kann, werde ich gleich erläutern.
• Daily Scrums z.B. werden teilweise wie ein Kaffeeklatsch behandelt oder – noch schlimmer – werden als Plattform für das Management verwendet um dem Team neue Priorisierungen mitzuteilen.
• Beliebt sind auch Sprintplanungen, in denen dem Team vorgeschrieben wird, wieviel Zeit es für welche Aufgaben haben darf.
• Teammitglieder erscheinen gar nicht oder zu spät zu Meetings.
• Daily Scrums beinhalten entweder zu viele oder zu wenige “Pigs” bzw. “Chickens” verhalten sich wie “Pigs”.
• Sprintziele bzw. Commitments werden nicht ernst genommen.
• …

Eine kleine Übersicht über Anhaltspunkte, dass es mit dem agilen Prozess nicht ganz so gut bestellt ist, gibt folgende Seite über Scrum-Smells.

Die Konsequenzen, wenn der “Gestank” (dt. für Smell) nicht berücksichtigt wird, sind einerseits lange Entwicklungszeiten und häufige Wartungsaktionen, da die Anforderungen nicht klar waren/sind oder Aufgaben permanent verschoben werden und andererseits Versuche Probleme mit klassisch bürokratischen Mitteln zu kompensieren, wie minutiös ausgearbeiteten Konzepten. Dadurch verlangsamt sich zusehends und dramatisch die Entwicklungszeit und damit die Reaktionszeit auf Kundenwünsche und Bugs. Ebenso wird die Flexibilität des Teams auf die reine Programmierung reduziert, die dann ggf. noch durch (von sich selbst übermäßig überzeugte) Code-Reviewer ad absurdum geführt wird.

Da dies kein komplettes Buch über die Vor- und Nachteile von Scrum respektive agiler Softwareentwicklung werden soll, möchte ich nur Folgendes festhalten:

Agile Softwareentwicklung besitzt genausoviel oder teils sogar mehr Formalismus als klassische Softwareentwicklung. Allerdings wird versucht den bürokratischen Aufwand zu reduzieren. Agil heisst hier vor allem, dass das Team wesentlich flexibler agieren und reagieren kann, als es in klassischen Prozessen ist und nicht, dass die Aufgabenstellung beliebig agil geändert werden kann. Dieser erhöhte Formalismus bedarf aber ebenso einer durchgängigen Disziplin aller Beteiligten. Ist diese Disziplin gegeben lassen sich auch innerhalb einer Iteration die Anforderungen bis zu einem bestimmten Grad ändern. Falls nicht, ist davon – wie es im Allgemeinen in der Literatur vorgegeben ist – abzuraten.

Leider ist es mit Trac immer noch nicht möglich unter einem Environment mehrere Projekte bzw. Repositories laufen zu lassen. Darum wird für jedes Projekt eine eigene Trac-Umgebung angelegt. Wichtig hierbei ist insbesondere für Firmen, dass alle Projekte zumindest in der Grundstruktur gleich aussehen und die Firmenfarben tragen.

“… was bisher geschah”

Wer zuerst probieren will, wie und was er alles anpassen kann, sollte sich das Verzeichnis templates unterhalb seiner Trac-Umgebung anschauen. Standardmäßig liegt dort die Datei site.html. Wenn man sie das erste Mal aufmacht, kommt sie sehr unscheinbar daher, denn wie man sieht, sieht man nichts. Nur einen html-Tag und ein paar unbekannt anmutende Python-Attribute.
Auf der Seite http://trac.edgewall.org/wiki/TracInterfaceCustomization ist glücklicherweise bereits ein Beispiel-Code für den Inhalt dieser Datei. Für jene, die gerne lieber mehrere Dateien nutzen wollen hier gleich die Anpassung mit Einbindung externer Dateien:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:py="http://genshi.edgewall.org/"
      xmlns:xi="http://www.w3.org/2001/XInclude"
      py:strip="">

  <!--! Add site-specific style sheet -->
  <head py:match="head" py:attrs="select('@*')">
    ${select('*|comment()|text()')}
    <link rel="stylesheet" type="text/css"
          href="${href.chrome('common/style.css')}" />
  </head>

  <body py:match="body" py:attrs="select('@*')">
    <!--! Add site-specific header -->
    <div id="siteheader">
       <xi:include href="site_header.cs">
         <xi:fallback />
       </xi:include>
    </div>

    ${select('*|text()')}

    <!--! Add site-specific footer -->
    <div id="sitefooter">
      <xi:include href="site_footer.cs">
        <xi:fallback />
      </xi:include>
    </div>
  </body>
</html>

Interessanterweise funktioniert das einfache Anlegen einer site_header.cs und site_footer.cs nicht immer – bzw. bei mir hat das noch nie funktioniert -, wie es auf manchen Seiten beschrieben wird.
Mit diesem Grundgerüst ausgestattet lässt sich schon anfangen herumzuspielen. Für weiterführende Informationen zu Genshi und Clearsilver – den Engines im Hintergrund – sei auf folgende Seiten verwiesen:

• http://genshi.edgewall.org/
• http://www.clearsilver.net/docs/

Neue und alte Freunde

Ein altbekannter Helfer beim Erstellen von Templates ist auch in der Version 0.11.5 noch vorhanden. Der Konfigurationsparameter template_dir.

[inherit]
template_dir=

Mit diesem Parameter lässt sich das Verzeichnis für die Templates festlegen und wodurch verschiedene Seiten mit ein und demselben Template ausgestattet werden können.

Daneben ist ein neuer Freund dazugekommen der Parameter htdocs_location. Mit diesem Parameter werden alle internen URLs, die mit “common/” beginnen in die URL umgeschrieben, die als Wert angegeben wurde.

[trac]
htdocs_location=http://localhost/mytemplate

Führt, dazu, dass aus

<link rel="stylesheet" href="/trac/templating/chrome/common/css/trac.css" type="text/css" />

folgendes wird

<link rel="stylesheet" href="http://localhost/mytemplate/css/trac.css" type="text/css" />

Achtung! Leider hat die Sache einen Haken. Eigene Links aus der site.html werden nicht übersetzt. Der folgende Code

${href.chrome('common/style.css')}

wird nur in "/trac/templating/chrome/common/style.css" umgewandelt, aber nicht weiter.

Wichtig ist außerdem zu beachten, dass htdocs_location nur für statische Inhalte, wie Bilder, JavaScript- und CSS-Dateien gedacht ist. Templates werden nicht automatisch von dort erkannt. Diese müssen explizit über template_dir konfiguriert werden. Leider ist es hier nur möglich lokale Verzeichnisse zu setzen. Wer z.B. versucht eine Internetadresse anzugeben, bekommt zwar keine Fehlermeldung, wird aber mit einem Standard-Template “belohnt”.

Abschließend möchte ich sagen, dass – gefühlt – wesentlich mehr über die trac.ini konfigurierbar ist, als es noch vor 2 Jahren der Fall war. Das macht definitiv Lust auf mehr, aber dennoch bleibt das ein oder andere noch zu tun.

Eclipse 3.5

Nachdem auf GTK+ 2.18 aktualisiert wurde, funktionieren diverse Buttons in Eclipse nicht mehr. Schnell wird man dank Google auf der Suche nach einem Fix bzw. Workaround fündig (Migrating to client-side windows). Offensichtlich ist die Umgebungsvariable GDK_NATIVE_WINDOWS für das Problem verantwortlich. Diese muss auf den Wert true gesetzt werden, damit SWT-basierte Java-Oberflächen (Anmerkung: auch andere Java-Applikationen mit SWT haben das Problem) wieder in altem Glanz erstrahlen.

#!/bin/bash
env GDK_NATIVE_WINDOWS=true <your/eclipse/path>/eclipse

(Den Pfad <your/eclipse/path> bitte an das jeweilige Installationsverzeichnis von Eclipse anpassen.)

Leider ist dies nur ein bescheidener Workaround, denn sobald man Eclipse aus sich heraus neu startet (z.B. nach Upgrades oder Plugin-Installationen) existiert das alte Problem wieder. Genauso, wenn man den Workspace versucht zu wechseln, da sich Eclipse auch hier herunterfährt und neu startet.

Ein richtiger Fix ist für die Version 3.5.2 angedacht bzw. soll in der 3.6 schon integriert sein, welche für die SDK-Variante bereits existiert. Nur für JEE-Developer wird es wohl noch etwas dauern.

Von einem globalen Umsetzen der Variable GDK_NATIVE_WINDOWS wird an diversen Stellen explizit abgeraten. Hier sei aber anzumerken, dass die Eclipse-Installation aus den Ubuntu-Repositories genau das macht. Für alle, die etwas “wagemutiger” sind hier das Startskript mit export.

#!/bin/sh

# work around e#290395 / LP: #458703
export GDK_NATIVE_WINDOWS=true

xuldir=/usr/lib/xulrunner-$(/usr/bin/xulrunner-1.9.1 --gre-version)
LD_LIBRARY_PATH=$xuldir${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} <your/eclipse/path>/eclipse
 "$@"

(Den Pfad <your/eclipse/path> bitte an das jeweilige Installationsverzeichnis von Eclipse anpassen.)

Dieses Skript am besten unter /usr/local/bin als eclipse ablegen und alle Links, die vorher direkt auf die Eclipse-Startdatei gegangen sind auf dieses Skript umbiegen.

Trac

Interessanterweise – was die primäre Motivation für diesen Kurzkommentar war – hat es auch das Bugtracking-Tool Trac erwischt. Zum Glück nicht so “heftig” wie Eclipse, aber dafür umso unverständlicher.

Ich habe lokal Trac mittels easy_install installiert gehabt. Nach dem Upgrade auf Ubuntu 9.10 erhielt ich plötzlich auf allen Trac-Seiten einen 500-Fehler. Nach kurzem Suchen fand ich in der error.log-Datei von Apache (Pfad unter Ubuntu: /var/log/apache2/error.log) folgenden Eintrag:

... [error] [client 127.0.0.1] ImportError: No module named genshi, ...

Warum das Modul plötzlich nicht mehr vorhanden war kann ich zum aktuellen Zeitpunkt nicht erklären, aber das war noch nicht das Ende.

Just in dem Moment wo ich mit

sudo easy_install Genshi

das entsprechende Modul installieren wollte, quittierte mir Ubuntu die Nachricht, dass easy_install nicht existiert. Ein kurzer Blick in Synaptic unter python-setuptools bestätigte die Vermutung, dass das Paket nicht installiert war. Ich möchte an dieser Stelle nicht ausschließen, dass es beim Upgrade in der Liste der zu deinstallierenden Pakete dabei war, aber dennoch ärgerlich. Also war auch hier nachinstallieren angesagt.

Zum Glück fügte sich dann alles sehr schnell. Das Genshi-Modul installierte sich ohne Probleme.

Abschließend musste noch der Workaround für einen Bug (http://trac.edgewall.org/ticket/7526) eingebaut werden. Einfach die compat.py im functional/tests-Ordner in testcompat.py
umbenennen und die compat.pyc in compat.pyc.old umbenennen oder gleich löschen.

Mit den Wochen und Monaten schwängerte sich mein Geist mit dem Gedanken sich an Trac “zu vergreifen” und selbst so eine Oberfläche zu schreiben. Zum Glück kam mir eine neue Anforderung in den Weg, die mir die Arbeit teilweise abnahm: der Wunsch eines Continuous Integration Systems – kurz CI.

Da ich schon gute Erfahrungen mit Hudson gemacht hatte, war die Entscheidung schnell getroffen das System auch für mich einzusetzen. Die Vorteile:

• einfache Installation
• Open Source
• kostenfrei

Allerdings musste gewährleistet werden, dass man damit Grails-Projekte bauen kann. Schaut man in die Plugin-Liste schreit es einen förmlich an: “Hier bin ich. Ist total easy-schneasy. Machs einfach!”

Aber wie so oft bei so offensichtlichen Aktionen liegt die Tücke im Detail. Leider hören – wie so oft – die Tutorials im Netz bei der Hälfte auf und vermitteln einem das Gefühl, dass man zu doof für die IT-Welt ist. Deshalb möchte ich hier einfach meine Erfahrungen bei der Einrichtung von Hudson mit den Grails- und Trac-Plugin auf einem Ubuntu-System vorstellen.

System

• Ubuntu 09.04
• Tomcat 6 (aus den Ubuntu-Repository)
• Trac (manuell installiert)
• Grails 1.1.1

Anmerkung
Ob Trac jetzt manuell oder aus dem Repository installiert wurde, ist eigentlich egal.

Hudson

Als erstes ging es darum Hudson zu installieren. Zwar bietet Ubuntu auch hier an über eine kleine Erweiterung der Repositories Hudson als Daemon zu installieren, allerdings bin ich persönlich kein großer Freund davon. Deshalb Alternative: war-File downloaden und einfach im Tomcat deployen.

Achtung!!! Wenn man das macht, sollte man vorsichtig beim Neustart aus Hudson heraus sein. Die Applikation fährt interessanterweise den Tomcat runter, bekommt ihn aber danach nicht mehr gestartet.

Zwei Dinge muss man dabei beachten, die aber auch auf der Hudson-Seite dokumentiert sind.

1. die Variable HUDSON_HOME muss gesetzt sein – habe ich bei mir direkt in das Tomcat-Startskript geschrieben (Faulheit siegt)
2. Es müssen teilweise noch Verzeichnis-Rechte angepasst werden, damit Hudson korrekt läuft

Nachdem Hudson nun endlich sein Pracht im Browser präsentiert geht es weiter mit dem Grails-Plugin.

Grails

Die Installation von Plugins ist in Hudson sehr simpel – oder wie manch Web 2.0-Entwickler sagen würde: “kissy” (von KISS – Keep it stupid simple). Einfach Häkchen setzen und auf “Installieren” klicken. Wie schon erwähnt, kann es hierbei dazu kommen, dass Hudson den kompletten Tomcat versucht neu zu starten, was zumindest bei mir nicht funktioniert hat. Ggf. einfach den Tomcat manuell neu starten.

Nachdem das Plugin installiert ist, müssen noch einige Konfigurationen durchgeführt werden. Als erstes muss der “Grails Builder” in der globalen Konfiguration von Hudson angelegt werden. Hier kann man verschiedene Grails-Installationen angeben, was insbesondere durch die teilweise Inkompatibilität der Versionen von großem Vorteil ist. Da die Sache in zwei Textboxen geregelt wird, verzichte ich mal auf den obligatorischen Screenshot.
Hat man jetzt die notwendigen Installationen angegeben kann man sich gütlich an die Konfiguration des Jobs machen. Hier muss ich vorausschicken, dass ich bereits einige Jobs angelegt hatte.

Unter dem Punkt “Build Verfahren” kann man über den Button “Build-Schritt hinzufügen” ein “Build with Grails” anlegen. Dabei lassen sich verschieden Werte konfigurieren. Nach einigem Herumprobieren waren aber nur drei relevant:

1. Grails Installation (wurde eben in der globalen Konfiguration angelegt)
2. Targets
3. grails.work.dir

Die Targets kann sich jeder selbst aussuchen aus der Liste, die “grails help” ausgibt. Bei mir sind das "test-app -unit --non-interactive" war doc.
Wichtig ist allerdings vor allem der Parameter grails.work.dir!

Das Grails-Plugin erwartet standardmäßig, dass es Zugriff auf das Verzeichnis /usr/share/tomcat6/.grails besitzt um auf den scriptCache zugreifen zu können. Da dieses Verzeichnis aber nicht zwingend freigegeben werden soll, muss ein alternatives Verzeichnis über grails.work.dir gesetzt werden. Andernfalls müssen die Zugriffsrechte mittels sudo chmod -R 777 /usr/share/tomcat6/.grails gesetzt werden.
Das Projekt-Verzeichnis hat noch eine weitere Bedeutung. Wenn man z.B. in Subversion seinen Code unter “trunk” eincheckt und keinen expliziten Modulpfad angelegt hat, wird automatisch trunk als Projektname auch in Hudson beim Bauen verwendet. Nun kann man sich vorstellen, dass bei mehreren Projekten, die alle in “trunk” liegen dies zu einer Überschneidung führt, die nicht unbedingt erwünscht ist.

Nichtsdestotrotz, bin ich hiermit bereits an das Ende meiner Vorstellung gekommen. Nach der Konfiguration des Jobs einfach auf “Jetzt bauen” klicken und schauen was passiert – ich hoffe mal es funktioniert. Ansonsten: bitte nicht hauen, bei mir läufts

Trac

Für alle, die jetzt fragend dastehen und wissen wollen: “aber er hat doch was von Trac erzählt”. Ja, das habe ich und ja, auch das geht sehr einfach. Nachdem man das Trac-Plugin installiert hat, erscheint ein Eingabefeld in der Job-Konfiguration, in dem man einen Link zum Trac-Projekt hinterlegen. Nachdem man diesen gespeichert hat, erscheint ein simpler Menüpunkt auf der Job-Seite “Trac”, der zu der entsprechenden Trac-Seite führt.

Leider sträubt sich Ubuntu ein wenig mit glanzvollen Alternativen. Ich habe versucht 3 Perlen herauszupicken und ich glaube es ist mir gelungen. Ich will nicht behaupten, dass es die besten sind, aber sie zeigen zumindest gutes Potenzial. Für Alternativen bin ich immer offen – einfach hier als Kommentar posten.

Planner

Der erste Kandidat um die Krone ist Planner. Dieses Werkzeug ist hervorgegangen aus dem direkten Pendant von MS Project, nämlich MrProject.
Ein Vorteil von Planner ist, dass es sich in den Standardrepositories von Ubuntu befindet. Leider ist es noch in seiner “Trotzphase”, insbesondere wenn es um den Import von MS Project-Dateien geht. Auch fehlen noch sinnvolle Reports. Man kann zwar den Plan ausdrucken, aber detaillierte Kostenaufstellungen sind nicht möglich.

GanttProject

Als zweites möchte ich GanttProject vorstellen. GanttProject befindet sich zwar nicht in den Repositories, aber wartet dagegen mit einigen visuellen Gimmicks auf. Es ist ein wenig bunter als Planner und ist der Konfigurationsmeister unter den vorgestellten Tools. An jeder “Klick-Ecke” findet man einen Menüpunkt zum konfigurieren von irgendwas. Meistens handelt es sich dabei um Darstellungselemente. Leider findet man auch hier keine Reporting-Funktion.

OpenProj

Komme ich damit zum dritten Kandidaten. OpenProj ist aus meiner Sicht das Tool für Manager, die sich neben der reinen Planung auch die Kosten stark im Auge behalten müssen und diese gerne in schriftlicher Form protokollieren wollen. Auf den ersten Blick kommt OpenProj mit wesentlich mehr Alternativ-Ansichten daher als Planner und GanttProject. Vor allem die Reportings können – nach kurzer Einarbeitungszeit – sehr nützlich sein. Auf der anderen Seite ist die Usability von OpenProj manchmal etwas holprig, so dass man gerade bei schnellen Aktionen eher ausgebremst wird (z.B. wird bei schnellen Klicken mal ein Eingabefeld geöffnet mal ein Popup angezeigt).

Weiteres findet man u.a. auf http://wiki.ubuntuusers.de/Projektmanagement

Für alle denen es aufgefallen ist: Ich habe nur GNOME-Tools vorgestellt. Da ich bei mir kein KDE verwende überlasse ich es anderen die Werkzeuge für diesen Desktopmanager vorzustellen.

FreeMind bietet viel freie Fläche zum Erstellen von Gedankenblasen – die müssen wirklich nicht immer sinnvoll gefüllt sein *gg*. Zusätzlich lassen sich auch gleich ein paar Icons hinzufügen um den Blick des Betrachters etwas zu führen, da es, wie so oft bei freien Gedanken, schnell unübersichtlich werden kann. Zwar hat man das bei FreeMind im Sinne des Mindmappings damit zu lösen versucht, dass die Gedanken baumstrukturiert dargestellt werden (siehe Screenshots) und Teilbäume ausblendbar sind.

Leider führt dies aber gerade bei umfangreicheren Konstrukten am Anfang genau ins Gegenteil und man ist mehr damit beschäftigt welche “Gedanken” auf welche Ebene gehören und in welchem geschlossenen Teilbaum sich gerade der benötigte “Gedanke” befindet. Außerdem sollte man unter Linux frühestens bei Version 0.8.1 beginnen, da vorher die Eingabe und Darstellung so fehlerhaft ist (z.B. Mausklicks funktionieren nur sporadisch, Darstellungsfehler beim Verschieben von Knoten), dass man nach einigen Minuten schon frustriert aufgeben will.

Leider lässt auch die aktuelle Version (0.8.1) noch Einiges an Benutzerfreundlichkeit offen – z.B. lassen sich spontane Gedankenzweige nicht unverknüpft anlegen oder Knoten lassen sich noch nicht mit Notizen versehen, was insbesondere in Kombination damit unpraktisch ist, dass Knoten standardmäßig einzeilig sind (man muss entweder Alt+Eingabe drücken oder im Kontextmenü “Knoten in einem separaten Editor bearbeiten …” auswählen um mehrere Zeilen schreiben zu können).

Und wieder muss ich mich bei Simonidossos für eine exzellente Empfehlung bedanken.

Das Buch “Der Termin” beschreibt diese und andere Situationen teilweise überspitzt. aber immer so, dass man sich darin wiederfinden kann.

Die Geschichte handelt von einem Softwaremanager – Mr. T. – , der von einem Entwicklungsparadies (ein einfaches Projekt mit scheinbar unendlichen Ressourcen und keinem Endtermin) in ein Worst-Case-Szenario erster Güte rutscht. Mit intelligenten Mitstreitern, vorteilhaften Zufällen und einem unerschöpflichen Vorrat an gutem Willen manövriert er durch (fast) alle Widrigkeiten.

Obwohl das Buch für einen Softwareentwickler bzw. Projektmanager sehr oberflächlich daherkommt und die Zufälle sehr konstruiert wirken um möglichst alle Probleme zumindest angeschnitten zu haben, liest sich das Buch sehr angenehm. Durch das Tagebuch innerhalb der Geschichte, dass der Protagonist schreibt, kann man sich einige Ansätze für das eigene Leben herausziehen und diese gemächlich überdenken oder sofort umsetzen.

Leider bietet Trac keine Möglichkeit über eine globale Variable das allgemeine Templateverzeichnis zu definieren. Man muss hierfür die trac.ini im Verzeichnis conf der jeweiligen Projektumgebung anpassen. In dieser Datei gibt es folgenden Abschnitt:

[inherit]
plugins_dir =
templates_dir =

Hier kann man das eigene Templateverzeichnis angeben, welches als Default verwendet werden soll.
Im Fall des Beispiels aus dem obigen Beitrag würde man den Eintrag

templates_dir = /home/testUser/trac/templates

setzen.

Nachdem man sich mit diversen Funktionen und Plugins in Trac “angefreundet” hat, stellt sich meistens die grundlegende Frage: “Wie kann ich das Design von Trac so ändern, dass es zu meinem Projekt passt”. Das fängt beim Logo an und hört bei der Anzeige der Projektliste auf – insofern man mehrere Projekte hat.

Trac bietet hierfür auf der eigenen Projektseite auch ein Tutorial, deshalb möchte ich hier nur eine kurze Einführung geben und dann auf ein paar Fallstricke bei der Individualiserung des Layouts eingehen, die in dem Tutorial nicht auftauchen. Auf das Ein- bzw. Ausblenden von Navigationspunkten oder die entsprechenden Verlinkungen wird hier nicht eingegangen.

Das Templatingsystem von Trac basiert auf Genshi, einer Pythonbibliothek, die es erlaubt Text aus diversen Quellen für das Web aufzubereiten. Trac bedient sich hierbei vor allem des HTML-Parsers.

In dem Verzeichnis trac/templates unterhalb des Trac-Installationsverzeichnisses befinden sich alle html-Dateien für das Default-Template. Insbesondere die layout.html und die index.html sind hier relevant. Die layout.html bestimmt das Aussehen der projektspezifischen Seiten und die index.html die Seite für die Projektliste. Unter trac/htdocs befinden sich die Bilder, Javascript-Dateien und die CSS-Dateien.

Trac bietet pro Projekt diverse Stellen zur Individualisierung des Designs an. Eine eigene site.html im Verzeichnis templates und ein eigenes Verzeichnis htdocs, in der eine style.css angelegt werden kann.

Um das Layout der Projektliste anzupassen sollte man folgende Zeile in die Konfigurationsdatei vom Webserver (z.B. die default von Apache) schreiben

SetEnv TRAC_ENV_INDEX_TEMPLATE "/home/testUser/trac/templates/index.html"

beim Setzen der Variable TRAC_ENV_INDEX_TEMPLATE muss darauf geachtet werden, dass sich das Verzeichnis templates nicht unterhalb des Elternverzeichnisses der Umgebungen (Environments) liegt. Wenn z.B. folgendes definiert ist

SetEnv TRAC_ENV_PARENT_DIR "/home/testUser/trac/"

kommt es auf der Seite für die Projektliste (definiert durch die index.html) zu einer Fehlermeldung, dass die Datei VERSION für das Projekt templates fehlt. Aus diesem Grund sollte die Variable TRAC_ENV_PARENT_DIR auf ein anderes Verzeichnis zeigen. Z.B.

SetEnv TRAC_ENV_PARENT_DIR "/home/testUser/trac/projects"

Nachdem diese Vorbereitungen getroffen sind, kann man daran gehen, die eigenen Templates zu entwerfen und umzusetzen.

Für projektspezifische Templates kann, wie bereits gesagt, die site.html verwendet werden. In dieser Datei ist vor allem der Ausdruck

${select('*|text()')}

relevant. Dieser wird in Verbindung mit

py:match="body"

verwendet und bedeutet soviel wie: “Nimm alle Subtags und jeden Text unterhalb vom Body-Tag”. Wenn man jetzt aber auf einzelne Elemente zugreifen möchte, z.B. nur den Content- oder den Main-Bereich, dann kann man folgenden Ausdruck verwenden:

${select('div[@id="main"]|text()')}

bzw.

${select('div/div[@id="content"]|text()')}

Der Ausdruck in der Select-Anweisung ist eine Untermenge von XPath (siehe hierzu Genshi XPath).

Leider bietet Trac scheinbar noch kein projektübergreifendes Templating an.

[Update]

Es gibt doch eine Möglichkeit. Siehe hierzu diesen Beitrag.

Weitere Informationen zum dem Thema befinden sich auf der Seite http://trac.edgewall.org/wiki/TracInterfaceCustomization, sowie ein Beispiel auf http://querdenker.kicks-ass.org/trac/querdenker/wiki/TracTemplating.