Es ließ sich Partout nicht starten und belegte mich mit der Meldung, dass meine “JAVA_HOME”-Variable auf ein invalides Verzeichnis verweisen würde. Leider konnte ich auf dem System nicht die JAVA_HOME direkt ändern, sondern musste diese in den Umgebungsvariablen des Benutzers “überschreiben”. Ist dann schon etwas unschön, aber gut – es ging erstmal ans Werk.

Nun ist man ja als alteingesessener Java-Entwickler daran gewöhnt, dass Pfade mit Leerzeichen nie gut ankommen. Also 1. Versuch: Leerzeichen entfernen – Kein Erfolg. Einmal ist keinmal, also nächster Versuch: Suchmaschine bemühen – wenig Erfolg.

Die Suche gab zwar nicht die vollständige Antwort, aber zumindest einen Anhaltspunkt. Der abschließende Backslash im Pfad könnte ein Problem sein. Zwar führte dieser Ansatz erstmal zu einem gewissen Erfolg, aber einfach mal eine Systemvariable überschreiben – auch wenn es nicht so große Unterschiede gab – fand ich nicht so “prickelnd”. Darum kam am Ende der Texteditor zum Einsatz, denn mir war aufgefallen, dass Groovy selbst z.B. keine Probleme mit dem Pfad hatte.

Und da war sie – die Lösung, die ich gesucht hatte:

@rem Remove trailing slash from JAVA_HOME if found
if "%JAVA_HOME:~-1%"=="\" SET JAVA_HOME=%JAVA_HOME:~0,-1%

Mit dieser Zeile wird einfach das abschließende Backslash entfernt. Diese Zeile in die startGriffon.bat unter :have_JAVA_HOME geschrieben und plötzlich funktioniert es auch mit dem Greif.

:have_JAVA_HOME
if "%JAVA_HOME:~-1%"=="\" SET JAVA_HOME=%JAVA_HOME:~0,-1%
@rem Validate JAVA_HOME
%COMMAND_COM% /C DIR "%JAVA_HOME%" 2>&1 | %FIND_EXE% /I /C "%JAVA_HOME%" >nul

Leider wurde das Problem auch in der aktuellen Version 0.3 nicht gefixt.

Was mir bei den meisten Howtos aufgefallen ist, dass sie schlechte Wartbarkeit hervorrufen und/oder irgendwas vergessen. Darum jetzt mein Versuch die Konfigurationsdateien der Welt unlesbar zu machen.

Die “Speisekarte” oder “Was will ich eigentlich”?

Tja. Für den einen oder anderen gezielten Sucher ist das schon klar, aber nochmal kurz für jene, die nur zufällig hier sind. Ich möchte in meiner URL nicht mehr http://localhost:8080 eingeben müssen um auf meinen Tomcat zu gelangen, sondern nur noch sowas wie http://tomcat.localhost. Ich hätte jetzt auch sagen können http://localhost, aber das wäre gelogen.

Installation der einzelnen Komponenten

Für die Installation nehme man eine Maus, Synaptic Paketverwaltung und zwei aussagekräftige Suchbegriffe wie tomcat6 und apache2. Für die Verknüpfung der beiden ist dann noch das Paket libapache2-mod-jk notwendig. Man würze das ganze mit einer Prise “Anwenden” und violá Apache 2 und Tomcat 6 sind installiert. Auf zu Schritt 2: die Dateien.

Die Dateien

Nichts läuft ohne eine anständige Konfiguration. Zur Vorbereitung lege man sich im Editor seiner Wahl folgende Dateien zurecht. Am besten mit sudo öffnen um darauf auch Schreibrechte zu haben.

• /etc/apache2/sites-available/default
• /etc/apache2/sites-available/mod_jk_vhosts
• /etc/apache2/mods-available/jk.conf
• /etc/apache2/workers.properties
• /etc/tomcat6/server.xml
• /etc/hosts

Die Dateien mod_jk_vhosts, jk.conf und workers.properties existieren höchstwahrscheinlich noch nicht. Darum diese bitte selbst anlegen.

Soweit diese “Vorspeise” abgeschlossen ist, wollen wir uns dem “Hauptgang” widmen: der Konfiguration

Die Konfiguration

Für die Konfiguration gehe ich jede der oben genannten Dateien einzeln durch und stelle eine mögliche Konfiguration vor. Diese Konfigurationen sind nur auf das notwendigste beschränkt. Falls weitere Optionen oder Alternativen notwendig sind, verweise ich gerne auf die entsprechenden Fachseiten.

mod_jk_vhost

Beginnen möchte ich mit der mod_jk_vhosts, da diese am umfangreichsten ist. Ich präsentiere … den Inhalt:

ServerName localhost
# NameVirtualHost *:80
<VirtualHost *:80>
	ServerName 127.0.0.2
	ServerAlias tomcat.localhost
	ServerAlias www.tomcat.localhost
	ServerAdmin webmaster@tomcat.localhost
	#Take note of the jsp content directory placement
	DocumentRoot /var/lib/tomcat6/webapps/
	<Directory "/var/lib/tomcat6/webapps/">
		Options Indexes FollowSymLinks +Includes
		AllowOverride All
		# DirectoryIndex index.jsp
	</Directory>
	#Mount the folders with jsp pages
	JkMount /* worker1
</VirtualHost>

<VirtualHost *:80>
	ServerName 127.0.0.3
	ServerAlias apache.localhost
	ServerAlias www.apache.localhost
	ServerAdmin webmaster@apache.localhost

	DocumentRoot /var/www
	<Directory />
		Options FollowSymLinks
		AllowOverride None
	</Directory>
	<Directory /var/www/>
		Options Indexes FollowSymLinks MultiViews
		AllowOverride None
		Order allow,deny
		allow from all
	</Directory>

	ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
	<Directory "/usr/lib/cgi-bin">
		AllowOverride None
		Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
		Order allow,deny
		Allow from all
	</Directory>

	ErrorLog /var/log/apache2/error.log

	# Possible values include: debug, info, notice, warn, error, crit,
	# alert, emerg.
	LogLevel warn

	CustomLog /var/log/apache2/access.log combined

    Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
	Options Indexes MultiViews FollowSymLinks
	AllowOverride None
	Order deny,allow
	Deny from all
	Allow from 127.0.0.0/255.0.0.0 ::1/128
    </Directory>
</VirtualHost>

Diese Datei wird anstelle der /etc/apache2/sites-available/default zukünftig für die Konfiguration des Apaches verwendet. Darum enthält sie auch große Teile der Original-Datei. Wenn der Inhalt der default-Datei anders aussieht, einfach den unteren Teil der mod_jk_vhosts-Datei mit dem Inhalt der default-Konfiguration abgleichen.

Zur Aktivierung der alternativen Konfiguration in der Konsole folgende Zeile ausführen:

sudo a2ensite mod_jk_vhosts

jk.conf

Die zweite Datei der ich mich widmen will, ist die jk.conf. Wie bereits erwähnt: sollte diese Datei noch nicht existieren, einfach unter dem oben genannten Pfad mit folgendem Inhalt speichern.

JkWorkersFile /etc/apache2/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info

Die Konfiguration ist sehr minimalistisch. Mehr wird auch erstmal nicht benötigt. Es wird nur die Stelle für die Konfigurationsdatei angegeben, die Apache braucht um mit dem Tomcat zu sprechen und die Logging-Konfiguration, für den Fall, dass etwas schief läuft.
Damit diese Konfiguration auch berücksichtigt wird muss sie mit

sudo ln -s /etc/apache2/mods-available/jk.conf /etc/apache2/mods-enabled/

verlinkt werden.

workers.properties

Die workers.properties kann man als das Herzstück der Konfiguration bezeichnen, da sie die eigentliche Kommunikation zwischen Apache und Tomcat ermöglicht.

workers.tomcat_home=/usr/share/tomcat6
workers.java_home=/usr/lib/jvm/java-6-sun
ps=/
worker.list=worker1
worker.worker1.port=8009
worker.worker1.host=localhost
worker.worker1.type=ajp13
worker.worker1.lbfactor=1

Der Kürze halber will ich an dieser Stelle nicht die einzelnen Parameter erklären, sondern nur auf die offizielle Dokumentation verweisen.

server.xml

Als dritte Datei kommen wir zur /etc/tomcat6/server.xml. Diese enthält die allgemeine Server-Konfiguration für den integrierten Tomcat von Ubuntu. An dieser Datei müssen zwei Änderungen durchgeführt werden:

1. Aktivierung von Port 8009 und
2. Server-Aliase für unseren VirtualHost setzen.

Für 1. einfach nach port="8009" suchen und die Zeile auskommentieren, sodass es in etwa so aussieht

...
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
...

Die Server-Aliase werden im Abschnitt Host eingetragen.

...
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
  ...
  <Alias>www.tomcat.localhost</Alias>
  <Alias>tomcat.localhost</Alias>
  <Alias>127.0.0.2</Alias>
  <Alias>tomcat.localhost</Alias>
</Host>
...

/etc/hosts

Als letzten Schritt soll auch Ubuntu erfahren zu welchem Servernamen welche IP gehört. Darum in die /etc/hosts folgende Zeilen hinzufügen:

127.0.0.2 tomcat.localhost www.tomcat.localhost
127.0.0.3 apache.localhost www.apache.localhost

Das “Dessert”

Auf das Dessert freut man sich ja eigentlich am meisten. So auch hier. Nachdem alles konfiguriert wurde, einfach den Tomcat und den Apache neustarten:

sudo /etc/init.d/tomcat6 restart
sudo /etc/init.d/apache2 restart

Violá, wir sind finis … zumindest was meinen Versuchsaufbau angeht. Falls noch alles läuft, habe ich was falsch gemacht. Im Ernst: Falls Kommentare sind, weil etwas nicht funktioniert bitte ich um User-generierten Content

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.

Da der Blog seit einiger Zeit Brach lag, musste eine Runderneuerung her. Nachdem die Software auf den aktuellen Stand gebracht wurde, fiel mein Augenmerk auf das Frontend. Ich weiss gar nicht mehr wie viele Jahre das alte Frontend ausgehalten hat, aber ich entschuldige mich hiermit nachdrücklich bei allen, die darunter leiden mussten.
Seit heute morgen erstrahlt der Blog in neuem Gewand und auch die Nutzbarkeit ist – nach eigenen Erfahrungen – erheblich gestiegen. Nebenbei sind diverse “Gimmicks” ins Template geflossen, wobei ich nicht verrate welche.

Dennoch stehen – jetzt, wo man alles lesen kann – die nächsten Umbauten an. Mit der Aktualisierung sind einige Probleme beim Encoding aufgetreten und einige Artikel müssen nochmal visuell nachgebessert werden. Ausserdem fehlen noch einige Zutaten zum “perfekten Glück”.

Ich werd mich dann mal weiter darum kümmern – Also viel Spaß beim stöbern.

Ich will an dieser Stelle weder die üblichen Lobeshymnen, noch die allseitsbeliebten Hasstiraden anstimmen, sondern nur eine kleine Hilfestellung geben, wenn man sich dazu entschließen will das GIT-Plugin von Hudson zu nutzen.

Die Installation ist zwar – wie immer – simpel, aber leider mag Hudson evtl. nicht gleich mit GIT “spielen”. Will man den Job starten kommt relativ schnell folgende Ausgabe in der Konsolenansicht.

Gestartet durch Benutzer anonymous
Checkout:workspace / /usr/local/apps/hudson_home/jobs/gitTest/workspace – hudson.remoting.LocalChannel@1063971
Last Build : #2
Checkout:workspace / /usr/local/apps/hudson_home/jobs/gitTest/workspace – hudson.remoting.LocalChannel@1063971
Fetching changes from the remote Git repository
Fetching upstream changes from file:///var/local/workspaces/experiments/sampleProject
[workspace] $ git fetch file:///var/local/workspaces/experiments/sampleProject +refs/heads/*:refs/remotes/origin/*
[workspace] $ git ls-tree HEAD
Seen branch in repository origin/master
Commencing build of Revision f7dc0e95f48a084d5192c3712f14b3353a98a876 (origin/master )
Checking out Revision f7dc0e95f48a084d5192c3712f14b3353a98a876 (origin/master )
[workspace] $ git checkout -f f7dc0e95f48a084d5192c3712f14b3353a98a876
[workspace] $ git tag -a -f -m “Hudson Build #3″ hudson-gitTest-3
FATAL: Could not apply tag hudson-gitTest-3
hudson.plugins.git.GitException: Could not apply tag hudson-gitTest-3
at hudson.plugins.git.GitAPI.tag(GitAPI.java:265)

[haufenweise stacktrace]

… 12 more
Caused by: hudson.plugins.git.GitException: Command returned status code 128:
*** Please tell me who you are.

Run

git config –global user.email “you@example.com”
git config –global user.name “Your Name”

to set your account’s default identity.
Omit –global to set the identity only in this repository.

fatal: empty ident <tomcat6@yourhost> not allowed

at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:297)
… 14 more

Offensichtlich ist GIT ein wenig schüchtern und mag nicht jeden an die digitale Wäsche ranlassen.

Leider findet man nicht wirklich eine Möglichkeit Hudson eine eigene Identität via Webfrontend zu geben. Der Trick liegt genau dahinter – und zwar im Dateisystem.

Genauer gesagt in der /etc/passwd. Aus irgendwelchen Gründen brauch GIT hier einen Eintrag im Feld für den fullName. Unter Ubuntu hat der Tomcat-User dort standardmäßig nichts gesetzt. Fügt man jetzt dort einfach ‘Tomcat 6,,,’ ein, läuft es auch mit dem CI-Nachbarn.

Alle, die sich über die Gründe Gedanken machen, seien auf die Git FAQs verwiesen.

So dann – viel Spaß beim Bauen.

Ohne jetzt auf die darauf folgende Odyssee mittels Googles ach so effektivem Suchalgorithmus eingehen zu wollen, fand sich die Lösung dann nach dem Ausschalten aller Trac-User-Heulattacken, die sich so durch die Bug- und Mailing-Listen ziehen.

DAS Problem

Wie so oft liegt das Problem nicht an der Stelle, die man sieht, sondern dahinter – weit dahinter in diesem Fall. Nämlich bei Ubuntu selbst. Es ist ja lieb gemeint, dass man immer die aktuelle Python-Version über Synaptic einbaut, aber dann sollte man das auch bei allen anderen Packages versuchen, die man so anbietet. In diesem Fall Trac. Denn was ist passiert? Leider sind die Versionen Trac 0.11.1 (Ubuntu Repository) und Python 2.6 (ebenfalls Ubuntu Repository) nicht kompatibel, was wohl auch schon eine Weile bekannt ist und selbst in Ubuntu-Foren ausgiebig “angeheult” wurde.

DIE Lösung

Man deinstalliere Trac über Synaptic und führe folgende Zeile aus:

sudo easy_install http://svn.edgewall.org/repos/trac/tags/trac-0.11.4

Danach erhält man u.a. eine nette Nachricht:

Installed /usr/local/lib/python2.6/dist-packages/Trac-0.11.4-py2.6.egg

Mit dem Enthusiasmus des aufgekommenen, osterlichen Eier-Such-und-Finde-Gefühls den Apache neustarten, evtl. das Environment upgraden und Tada: Alles schick!

Die Frage ist also: “Was bringt Web 3.0?” – wenn es so etwas überhaupt noch geben wird. Eine Konferenz, die aktuell stattfindet befasst sich genau mit dieser Frage. Wird das Web 3.0 das Social Semantic Web?

Nehmen wir mal an, das es so kommen wird. Welche Geschäftsmodelle bringt Web 3.0? Nachdem bereits im Web 2.0-Sumpf die eine oder andere Million versackt ist, frage ich mich, was soll etwas so “schwammiges” wie die Kombination aus Social Communities und Semantic Web an planungssicheren und vor allem nachhaltigen Modellen oder Ideen liefern?
Wird es abseits aller “technischen Spielereien” durch die Einführung semantik-basierender Algorithmen überhaupt eine Neuerung geben?  Stehen wir schon im Web 3.0 und hat es die Marketingabteilung noch nicht gemerkt?

Es bleiben also 3 große Fragen, abseits der Technik:

1. Welche inhaltliche Entwicklung bringt uns die nächste Stufe des Webs?
2. Welche Geschäftsmodelle sind für ein Social Semantic Web sinnvoll?
3. Wie gewährleistet man freien Zugang zu verwertbaren Inhalten?

Eine Entwicklung, die sich bereits abzeichnet ist die Entstehung von “gemeinnützigen” Seiten. D.h. neben dem “wir sind alle freunde”-Prinzip von Plattformen wie Facebook, Lokalisten oder MeinVZ steht soziales Engagement à la http://www.betterplace.org im Vordergrund.
Doch können sich solche Plattformen selbst tragen, ohne sich “zu verkaufen”, wie es so schön heisst. Welche Möglichkeiten stehen zur Verfügung, wenn Werbe-, Abonnement- und Premiummodelle nicht mehr greifen? Will ich mein eigenes Engagement teuer erkaufen?

Ein anderer Aspekt, der Grundlage der Entwicklung von Web 3.0 ist, ist die wachsende Datenflut. Insbesondere durch Web 2.0 hat sich der Datenumfang drastisch erhöht. Dadurch ist die zentrale Verwaltung von Daten nicht mehr sinnvoll umsetzbar. Es wird nötig dezentrale Daten über ein ausgeklügeltes Mapping von Metadaten zu Orten im Netz auffindbar zu machen.

Doch hier bleibt die Frage nach der Verfügbarkeit eines solchen Dienstes, wobei vor allem zwei verschiedene Ansätze ins Spiel kommen. Einerseits werden spezifische Inhalte hinter digitale Panzertüren gelegt, so dass nur noch zahlende Kunden an diese Informationen herankommen. Andererseits werden die Dienste, die auf eigentlich freie Daten zugreifen können ebenfalls kostenpflichtig angeboten (Premiumdienste) um verwertbare Ergebnisse zu erhalten.
Hier muss, meiner Meinung nach, ein gewisses Umdenken bei bestimmten Stellen einsetzen. Qualität hat seinen Preis, aber qualitatives Wissen sollte nicht einer Elite vorbehalten sein.

Im Rahmen eines Craptecs-Projektes soll im Laufe der nächsten Wochen eine Implementierung für das ICQ-Protokoll erstellt werden (siehe http://craptecs.blogspot.com/2009/03/proof-of-concept-icq-via-mina.html).

Wer Interesse daran hat, kann sich gern bei mir persönlich melden oder das craptecs-Team per IRC auf irc.freenode.org Kanal #craptecs aufsuchen. Wir würden uns freuen.

Der Wrapper basiert auf dem Widget-Prinzip. D.h. alles ist ein Widget. Von der Seite bis zum Formular. Aktuell stehen folgende Widgets zur Verfügung:

• Page: Eine normale Seite
• Section: Seitenbereich, kann auch eine komplette Unterseite darstellen
• Form: normales Formular
• Menu: diverse Ausprägungen eines Menüs

Jedes Widget kann mit einem Template individualisiert werden. Diese können unter custom/templates erstellt werden, da sich unter widgets die Standardtemplates befinden und diese auch nicht geändert werden sollten. Beispiele befinden sich in dem Verzeichnis samples.

Download: pinc-soow.zip

Notelib Release

Es ist soweit, die neue Version von PINC-Notelib ist online. Unter PINC-Apps finden sich die Downloadlinks für die Binär- und die Sourcecodeversion. Außerdem gibt die Featureliste einen groben Überblick über die enthaltenen Funktionen, die die Applikation bereithält.
Ich will darauf hinweisen, dass es sich dabei um eine Webapplikation handelt und einen Servletcontainer (z.B. Tomcat) zum laufen benötigt.

PINCservices.de in “neuem” Gewand

Nach einiger Überlegung habe ich mich dazu entschieden die Ausrichtung von PINCServices zu ändern. Es wird von einem reinen Auftragsgeschäft zurücktreten und sich auf die Erstellung von Webapplikationen auf Grails- und Java-Basis konzentrieren.

Mit den inhaltlichen Änderungen kommen auch ein paar technische Neuerungen einher. So wurde der Unterbau der Homepage von pincservices.de ein wenig aufpoliert. Mit Savant3 (http://www.phpsavant.com) steht dafür eine sehr angenehme Templating-Engine zur Verfügung.