Das Perl Template Toolkit (TT2) ist in der Version 2.24 auf dem Weg zum CPAN. Wer ungeduldig ist, kann sich die neue Version auch hier herunterladen (tar.gz, 500 KB). Neu sind ein paar neue Textoperationen und es gibt auch ein paar Bugfixes.

Denn bei all meiner (wiedererwachten) Begeisterung für RubyFrontier. Für komplexere Aufgaben ist TT2 sicher das bessere Werkzeug, das ich nicht aus den Augen verloren habe — auch wenn der Einstieg erst einmal schwieriger ist. [TT2 Mailingliste]

Andy Wardley hat vor ein paar Tagen die Version 2.23 des Perl Template Toolkits (TT2) hochgeladen. Es ist ein Wartungs-Release mit ein paar Bugfixes und ohne neue Features. Aber es zeigt, daß die Software doch noch aktiv weiterentwickelt wird. Und das freut mich …

Außerdem wurde die Dokumentation komplett neu überar­beitet und kann hier heruntergeladen werden.

Ich werde versuchen, möglichst regelmäßig weitere Abschnitte hinzuzufügen und Euch in diesem Blog darüber informieren. Habt Spaß damit. Anregungen und Kommentare sind willkommen, aber seid bitte nachsichtig mit mir. Der Text ist noch sehr alpha und die meisten Tippfehler sind auch noch nicht korrigiert …

Das Perl-Skript Perlator (GPL) erzeugt aus speziell formatierten Textdateien und einer in HTML und mit wenigen Steueranweisungen gestalteten Vorlage eine komplette Website.

Es generiert nicht einfach nur mehr oder weniger lose zusammen­hängende HTML-Seiten, es ist auch in der Lage, umgekehrt chronologisch sortierte Ansichten von Nachrichten zu generieren, wie man sie etwa von Blogs her kennt. Außerdem entstehen Newsfeeds in den Formaten RSS 0.9, 1.0 und 2.0, die jeder halbwegs aktuelle Newsreader zu interpretieren weiß. Als Orientierungshilfe für den Google-Searchbot erstellt das Skript eine Sitemap und informiert Google gegebenenfalls über das Vorliegen einer neuen Sitemap.

Sämtliche entstandenen HTML- und XML-Dateien sowie alle dazugehörigen Inhalte wie Bilder, PDFs, Videos et cetera überträgt das Skript automatisch per FTP zum Webserver, und zwar nur die, die sich seit dem letzten Upload geändert haben. Ob sich eine Datei geändert hat, stellt das Skript anhand eines MD5-Hash fest, den es nach jedem Upload aus der Datei errechnet und diesen mit dem gespeicherten vergleicht.

Perlator basiert auf dem Perl Template Toolkit und ist eine Eigententwicklung des Heise-Verlags. Notiz an mich: Unbedingt testen! [Peter van I. per Email.]

Eine Frage an der TT2- und Perl-Community da draußen: Kennt jemand ein Modul oder Skript für das Perl-Template-Toolkit, das für Code-Schnipsel in Webseiten ein Syntax-Coloring bietet? (Aktuell hätte ich das gerne für Java- und Python-Code.) Oder gibt es alternativ irgend ein Standalone-Skript, durch das man solche Code-Schnipsel jagen kann und das dann HTML ausspuckt, das die Sprachelemente entsprechend einfärbt? Da ich statische (HTML-) Seiten nicht unbedingt per Hand einfärben möchte, bin ich für jeden Tip oder Hinweis dankbar.

[1]: Nicht immer, aber immer häufiger nutze ich den Aquamacs für die Erstellung speziell umfangreicher LateX-Dokumente. Das liegt zum einen an AUCTeX und zum anderen daran, daß AUCTeX zusammen mit dem freien PDF-Viewer Skim eine komfortable, immer synchronisierte Druckansicht des Dokuments liefert. (Allerdings ist dies nur mit großen Monitoren wirklich komfortabel, auf meinem Laptop verdeckt Skim immer das Aquamacs-Fenster, daher nutze ich dort zur Preview lieber weiterhin TeXShop.)

Bisher wäre es mir aber nie in den Sinn gekommen, daß man den Aquamacs auch für andere Zwecke einsetzen kann. Bis ich gestern schnell mal eben zum Nachschlagen ein Python-Dokument geladen hatte und dann feststellte, daß im Python-Mode der Aquamacs auch einen (internen) Python-Interpreter zur Verfügung stellt. Nett …

[2]: TextMate (kommerziell) ist ja ebenfalls ein unter MacOS X beliebter Editor. Die Seite »Essential TextMate Shortcuts, Tips and Techniques« bringt ein paar Tricks, die ich auch noch nicht kannte. [Peter van I. per Email.]

Screenshot Textwrangler mit Disk-Browser

[3]: Wo wir gerade bei TextMate sind: Bisher hatte ich diesen Editor in der Hauptsache für meine Experimente mit dem Perl Template Toolkit verwendet, weil ich die Projektansicht dafür enorm praktisch fand. Gestern hatte ich versehentlich einen ganzen Ordner auf das TextWrangler-Icon geschoben und dann festgestellt, daß auch dieser freie (frei wei Freibier) Editor eine ganz passable Directory-Ansicht und Projektverwaltung besitzt (die im Bar-Bones-Jargon Disk Browser heißt). Wahrscheinlich bin ich der Letzte, der das gemerkt hat, aber falls noch jemand von Euch da draußen es auch noch nicht wußte …

Ich hatte mich die letzten Monate mit meiner Unentschlossenheit, ob nun das Perl Template Toolkit (TT2) oder RubyFrontier mein nächstes Werkzeug für statische Webseiten werden wird, selber ziemlich lahmgelegt. Nachdem ich die letzte Zeit eigentlich verstärkt auf RubyFrontier gesetzt hatte (zum Beispiel in meinem Testbett), habe ich an diesem Wochenende intensiv mit dem Template Toolkit gespielt und nun sind die Würfel gefallen.

Ich habe das Grundgerüst einer Site mit hierarchischer Navigation, Next-Prev-Navigation und einem hierarchischen Krümelpfad. Der Einstieg war nicht leicht, denn das Template Toolkit ist anfangs bedeutend sperriger als RubyFrontier, aber es lohnt sich:

1. Man kann viel mehr als in RubyFrontier mit bordeigenen Mittel erledigen und muß nicht eine externe Programmiersprache bemühen — obwohl das natürlich auch geht. Und da ist mir Perl um einiges lieber (weil ich es schon so lange kenne, vermute ich); mit Ruby bin ich einfach nicht warm geworden.
2. Das Perl Template Toolkit ist um einiges schneller als RubyFrontier, beim letzteren kostet der eigentlich nützliche Glossary-Mechanismus bei großen Sites (mit vielen tausend Seiten) zu viel Zeit.
3. TT2 ist älter und dadurch ausgereifter. Trotzdem wird es noch aktiv weiter entwickelt (TT3 steht (irgendwann) vor der Tür.) Und auf der Mailingliste ist auch mehr los.

Was ich vermisse, sind die Wiki-ähnlichen Links, die RubyFrontier ermöglicht. Aber dazu braucht es eben den oben geschmähten, zeitverschlingenden Glossary-Mechanismus.

Bei meinen Erkundunge half mir das Buch zum Toolkit weiter — ohne geht es glaube ich auch kaum. Leider hat es einige Fehler, zwei davon haben mich sehr lange aufgehalten:

1. Das Verzeichnes images muß im Verzeichnis src liegen und nicht darüber.
2. Die vorherige Seite bekommt man natürlich mit loop.prev und nicht mit loop.last.
3. Und es gibt noch ein paar Flüchtigkeitsfehler dieser Sorte …

Trotzdem hilft einem das Buch, die Philosophie hinter den Toolkit zu verstehen. Man sollte nach einer ersten Lektüre die Beispielanwendung im 11. Kapitel unbedingt einmal komplett selber nachvollziehen — danach ist man schlauer.

Hilfreich ist auch ein Editor, der Projekte verwalten kann. An diesem Wochenende habe ich deswegen TextMate zum ersten Mal so richtig schätzen gelernt.

Und ein Webserver auf dem Desktop ist natürlich extrem nützlich. Ich habe auf meinem Macs MAMP dafür genutzt und TT2 die fertigen Seiten direkt in MAMPs htdoc-Verzeichnis schreiben lassen.

Ich werde das Gelernte erst einmal in einem Buchprojekt einsetzen (mehr dazu, sobald ich mehr habe). Ich hoffe, dabei so viel über TT2 zu lernen, daß ich im Anschluß daran den Schockwellenreiter damit statisch umsetzen kann (momentan ist mir allerdings noch völlig schleierhaft, wie ich aus den Blogposts möglichst automatisch die Archivseiten und den RSS-Feed generiere (aber das weiß ich auch bei RubyFrontier (noch) nicht).

Wenn ich mich jetzt noch entscheiden könnte, ob ich die dynamischen Teile mit Googles App Engine oder mit Django generiere, wäre ich noch weiter. Still diggin’!

Die erwähnten Desktop-Datenbanken sind aber in der Lage, ihre Daten als Textdateien (mit ein wenig drumherum) herauszugeben, so daß eine Template-Engine in der Lage ist, daraus mit Hilfe eines Templates Webseiten herauszurendern. Bis vor kurzem war das Perl Template Toolkit für solche Arbeiten das Werkzeug meiner Wahl, denn es ist wirklich sehr, sehr leistungsfähig. Doch leider erkauft man sich diese Leistungsfähigkeit mit einem schwerwiegenden Nachteil. Bedingt durch die Komplexität ist der gemeine Wissenschaftler an sich nicht in der Lage, dieses Toolkit ohne Hilfe einer EDV-Abteilung zu konfigurieren und seine Webseiten herauszuschreiben. Frontier resp. der OPML Editor hingegen sind erst einmal so einfach, daß nach kurzer Einarbeitung jeder damit arbeiten kann.

Und hier kommt Matt Neuburgs RubyFrontier ins Spiel. Es ist ähnlich einfach wie Frontier oder der OPML Editor (es ist ja schließlich so etwas wie ein Frontier-Klon), nur, daß das Tool statt auf einer odb auf Text-Dateien arbeitet (Outlines erwartet RubyFrontier als OPML-Dateien … und das sind XML-Dateien, also auch Text pur). Meine bisherige Strategie sieht so aus: Der eigentliche Content wird — wie auch immer (z.B. über FileMaker) — aufbereitet und auf einem Rechner im Netzwerk, den RubyFrontier erreichen kann, zur Verfügung gestellt (in einigen Fällen habe ich noch ein Versionsverwaltungssystem dazwischenge­schaltet, um die Konsistenz der Daten zu sichern). Dann läuft die Template Engine darüber und erstellt statische Seiten für die Webpräsenz. So lassen sich relativ schnell und ziemlich einfach auch größere Sammlungen ins Netz stellen — warum nicht auch ein P2P-flickr?

Für den Community-Teil gilt das im ersten Teil dieses Beitrags gesagte, aber dieses Beispiel zeigt auch, daß die einzelnen Teilnehmer solch eines P2P-Netzes nicht die gleichen Werkzeuge benutzen müssen, um miteinander kommunizieren zu können. Denn egal, ob ich RubyFrontier, den OPML Editor, das Perl Template Toolkit oder Django benutze, solange ich mich auf offene Standards und Protokolle einige, funktioniert auch die Kommunikation.

(In meinen Kommentaren zum ersten Teil schlug Thomas vor, PubSubHubbub statt XMPP zu nutzen, ein interessanter Ansatz, den ich weiterverfolgen werde.)

What’s next? Seit einiger Zeit lade ich alle meine Photos nicht nur zu flickr, sondern — als Backup meiner lokalen Festplatte — auch auf Amazons S3 hoch. Um Ruby zu lernen, werde ich mich — sobald ich wieder etwas Luft habe — mal an ein Ruby-Script versuchen, das daraus mit Hilfe von RubyFrontier eine statische P2P-flickr-Instanz (mit Photos und Videos) zaubert und die mit der im ersten Teil entworfenen OPML-Editor-basierten P2P-flickr-Instanz »spricht«. Wäre doch erst einmal ein netter Anfang …

Ansonsten habe ich viel vor: Ich besitze zum Beispiel eine große Sammlung historischer (Musik-) Noten, die ich so relativ problemlos ins Netz stellen könnte.

Und über die Webseiten, die in meinem beruflichen Umfeld mit RubyFrontier erstellt werden, berichte ich, sobald sie öffentlich zugänglich sind.

Daher schmerzt es zu erfahren, daß UserLand Software zum 31. Dezember dieses Jahres seine Pforten für immer schließt. Nicht nur, weil ein weiterer Web-Pionier das Zeitliche gesegnet hat, sondern auch und gerade für die unentwegten Radio UserLand- und Manila-Nutzer, die ihren Hoster verlieren.

Und in der Community werden eifrig (und auch ein wenig verzweifelt) die Alternativen diskutiert. Klar ist, daß Open Source Frontier seit Jahren nicht wirklich weiterentwickelt wurde und so kommen für die einen Matt Neuburgs Ruby-Spielzeuge rb-appscript und RubyFrontier in Frage, während andere auf Django und Python setzen.

Mein derzeitiger Favorit für die Generierung großer Mengen statischer Seiten ist das Perl Template Toolkit. Doch obwohl ein sehr mächtiges Werkzeug, fehlt mir doch manchmal die Eleganz, die dem Vererbungsmechanismus von Frontier, aber auch Zope zu eigen war. Aber es sieht so aus, als ob es momentan keine Alternative dazu gäbe …

Trotzdem habe ich beschlossen, mir in den nächsten Tagen Django intensiver anzuschauen. Schon allein, weil das Teil auch mit der Google App Engine harmoniert und daher für die Programmierung von Googles Wellen nützlich sein kann. Und weil ich nach Strategien suche, wie große Sammlungen schnell und komfortabel ins Netz gestellt werden können, ohne daß der Nutzer gleich ein Informatikstudium absolviert haben muß. Mehr darüber in den nächsten Tagen.

Hier denke ich weniger an eine Blog Engine als an einen Ersatz für das alte Frontier Static Site Tool, das ja bekanntlich leider schon lange nicht mehr gepflegt wird und mit dem ich viele Webauftritte realisiert hatte (unter anderem über Jahre auch den Schockwellenreiter). Wie gesagt, das Teil ist so ohne weiteres nicht gerade eine Blog-Engine — obwohl man sie sicher dazu aufbohren könnte —, aber ich denke dabei auch eher an Sites wie die Nigeria-Connection oder auch an die vielen Sammlungs-Seiten am Institut.

Der Nachteil dieses Toolkits ist, daß es lokal auf dem Desktop installiert sein muß. Aber bei meinen bisherigen Test habe ich die Daten auf der Dropbox abgelegt und konnte auf sie ohne Probleme von meinem Desktop zu Hause, von meinem Laptop unterwegs und von meinem Desktop am Institut zugreifen — eine funktionierende Internet-Verbindung vorausgesetzt.

Natürlich ist Dropbox nicht gerade ideal, wenn mehrere Personen die Daten bearbeiten und publizieren wollen, aber mit einem Versionsverwaltungssystem wie Git oder Subversion könnte man Konflikte vermeiden und die Daten zentral zur Verfügung stellen. Und das Perl Template Toolkit greift auf Textdateien zu, die irgendiwe (zum Beispiel auch via Skript) zur Verfügung gestellt werden — ideal für große Sammlungen.

Das Perl Template Toolkit muß natürlich auch nicht auf allen Rechnern installiert sein. Es wird ja nur dort gebraucht, wo die Berechtigung zum Publizieren vorhanden ist. Das heißt: Viele stellen mit ihren gewohnten (Textverarbeitungs-) Werkzeugen mithilfe eines CVS die Daten zur Verfügung und ein Redaktionsserver stellt diese als statische Seiten ins Netz. Einfacher kann ein CMS nicht funktionieren …

• Migrating A Largish Site From WordPress to MovableType 4 ist ein älterer Beitrag aus dem Jahre 2007.
• Heute scheint es einfacher zu gehen, wenn man die Kürze dieses Beitrags betrachtet: Moving From WordPress To Movable Type.

Dabei geht es mir gar nicht so sehr darum, mein WordPress-Blog nach Movable Type zu transportieren, die paar Monate kriege ich schon irgendwie statisch, im schlimmsten Falle mit curl oder wget. Was ich möchte, ist das Beste aus beiden Welten:

1. Die Möglichkeit, von überall im Netz mein Blog füttern und administrieren zu können.
2. Die Geschwindigkeit, Einfachheit und Sicherheit, die mir statische Seiten bieten (schließlich sind vom Schockwellenreiter nur die Seiten (aus 2000) verschwunden, die ich dynamisch bei EditThisPage hosten ließ und dann fehlen ein paar hundert Bilder aus der Zeit, als mein Weblog dynamisch mit COREblog, einer Zope-Applikation betrieben wurde — die eigentlichen Webseiten hatte ich rechtzeitig vor dem Server-Crash und etwas mühselig mithilfe von wget zu statischen Seiten gemacht).

Momentan finde ich zwei Ideen ganz charmant:

1. Ich reaktiviere meine Räume in der Server-WG und lasse dort Movable Type als Redaktionsserver laufen. Und schicke von dort statische Seiten entweder weiterhin zum Spielzeugprovider oder direkt nach Amazons S3. Ich hätte die von mir schon immer geforderte Trennung von Redaktions- und Produktionsserver und gleichzeitig die Gewißheit, mit den statischen Seiten eine leicht zu sichernde Version des Schockwellenreiters irgendwo zu Backup-Zwecken zusätzlich noch einmal ablegen zu können.
2. Oder ich gehe ganz in den Cloud. Googles App Engine hat es mir eigentlich schon immer angetan, mit einem von mir in Python geschriebenem Template Toolkit, das statische Seiten herausrendert, hatte ich den Schockwellenreiter schon einmal ein paar Jahre betrieben, warum nicht so etwas, vieleicht mit Hilfe des Django-Frameworks für Googles Cloud entwickeln, das dann ebenfalls statische Seiten nach Amazons S3 herausrendert? Auch in diesem Falle wären Redaktions- und Produktions­server getrennt und es gilt ebenfalls das für statische Seiten im Abschnitt oben Geschriebene.

Aber ich bin mit meinen Überlegungen noch nicht fertig: Eine weitere in meinem Hinterkopf schwebende Option wäre nämlich, mein Blog mit meinem Wiki zu verschmelzen. Mir gefällt die Einfachheit des Markup-Codes von DokuWiki und die Möglichkeit, ohne die starre Einteilung in Überschrift und Blogbeitrag (und ohne die starre zeitliche Reihenfolge) publizieren zu können — meine Kurzbeiträge brauchen nämlich manchmal keine Überschrift, die ich mir dann erst mühselig aus den Fingern saugen muß.

Sicher, ich hätte dann nicht die Trennung von Redaktions- und Produktions­server und das DokuWiki rendert auch keine statischen Seiten heraus. Aber immerhin versenkt es seine Inhalte nicht in eine Datenbank, sondern legt sie brav in leicht zu sichernde und wieder zu lesende Textfiles ab.

Und irgendwie ist auch das Perl Template Toolkit noch nicht völlig aus dem Rennen.

Ihr seht, sooo schnell wird eine Änderung hier nicht passieren. Der Leidensdruck ist momentan noch nicht so groß und ich muß noch ein wenig nachdenken …

Da es mit dem Perl Template Toolkit zusammenarbeitet, kann das Teil bestimmt auch statische Seiten herausrendern. Ich glaube, ich sollte es mir unbedingt einmal genauer anschauen.

• Mein bisheriger Favorit ist das Perl Template Toolkit. Ich habe mich in den letzten Wochen mit Hilfe dieses Buches wieder ein wenig darin eingearbeitet — das ist aber auch nötig, denn die Lernkurve am Anfang ist ziemlich steil. Aber dafür ist das Teil ziemlich flexibel. leistungsstark und kann beliebig erweitert werden. Die Installation unter MacOS X ist einfach.
• Heute machte mich Jan in meinen Kommentaren auf die Website Meta Language aufmerksam. Dieses ebenfalls in Perl (mit einem Kern ANSI-C) geschriebene Tool macht auf den ersten Blick ebenfalls einen hervorragenden Eindruck und wird von mir getestet werden.
• RubyFrontier habe ich auf meinen Macs leider nicht installiert bekommen. Und ich befürchte fast, daß mir dies mit den anderen netten Ruby-basierten Tools von gestern ähnlich ergehen wird.

Falls jemand von Euch da draußen noch einen Tip hat, nehme ich ihn gerne in meinen Kommentaren entgegen.