Modularie

Perl-Module zu installieren ist ein Ritual; ein gleichförmiges und einfaches. Manchmal allerdings hinkt die eigentliche Arbeit der Installation weit hinterher.

vorlesen Druckansicht
Lesezeit: 5 Min.
Von
  • Henning Behme

Innerhalb des XSLT-Tutorials, dessen dritter Teil in diesem Heft zu lesen ist, war geplant, die serverseitig-dynamische Verarbeitung von XML-Dokumenten vorzuführen. Dazu sollte das von Matt Sergeant entwickelte AxKit als ‘Application Server’ dienen und on-the-fly HTML an die Clients ausliefern.

Bei AxKit handelt es sich um ein Perl-Modul, das in die lokale Perl-Installation des Webservers zu integrieren ist. Erster Schritt zur Einbindung von Perl-Modulen ist jeweils perl Makefile.PL. Hier erhält man Meldungen zu Modulen, die noch nicht Bestandteil der lokalen Perl-Installation sind; in diesem Fall waren das

Apache::Request 0
Compress::Zlib 0
Error 0.13
Storable 0.6
Time::HiRes 1.2
Unicode::Map8 0.1 (nicht mehr in AxKit 1.2)
Unicode::String 2.06
XML::Sablotron 0.4
XML::XPath 0.55

Solche Nach- beziehungsweise Vorarbeiten sind meist schnell erledigt - wäre Apache::Request auf dem CPAN-Server zu finden gewesen. Zumindest unter diesem Namen keine Chance. Aber die heute selbstverständliche Suche nach dem Modul bei der Suchmaschine der Wahl bringt schnell zu Tage, dass es sich innerhalb des Moduls libapreq befindet, das wiederum bei CPAN vorhanden ist. Danach war das übliche make; make test; make install in Sekundenschnelle erledigt [Alternative: in einem Shell-Fenster perl -MCPAN -e shell eingeben und mit install <module> installieren]. Lediglich eine kleine Änderung in Makefile.PL war erforderlich, um die letzte Warnung zu beseitigen:

Warning: prerequisite Apache::Request 0.3103 not
found at (eval 1) line 228.

Die Lösung: Versionsnummer in Makefile.PL auf 0.31 ändern ... Für den Fall, dass Sabletron als XSLT-Prozessor gewünscht ist, gilt es, erst sourceforge.net/projects/expat besorgen und installieren, anschließend Sablotron von www.gingerall.com/ holen und installieren ... Nun klappts auch mit dem gesamten Paket.

Plötzlich funktionierts. Vorausgesetzt, jedes Verzeichnis, das über den Apache für AxKit vorgesehen ist, enthält ein Unterverzeichnis namens .xmlstyle_cache, das für den Benutzer, der den httpd-Prozess anstößt, beschreibbar ist. Oder über die Apache-Direktive für ein Verzeichnis (Location) ist per

AxCacheDir /pfad/zum/axkit_cache

ein generelles Cache Directory gesetzt, das wiederum für den Apache-Benutzer (nobody) beschreibbar sein muss.

Leider hat die Sache einen Haken: AxKit hält Dateien zwar im Cache vor, berücksichtigt dabei aber nicht, ob sich der Query-String bei einem Aufruf ändert. Etwa das myentry=html in dem Link

<a href="woerterbuch.xml?myentry=html">...</a>

Da die XML-Datei woerterbuch.xml sich im Cache befindet, muss aus Sicht des Apache (und darin AxKit) nichts geändert werden, obwohl das Ergebnis ein völlig anderes Dokument auf der Clientseite ergibt. Die korrrekte/aktualisierte Anzeige war für das genannte Tutorial notwendig, was für ein erstes Ins-Schwitzen-Kommen sorgte.

Abhilfe schafften in diesem Fall Zugriffe auf die AxKit-Quellen, im einfachsten Fall auf Cache.pm. Dort steht in Zeile 31 (nach der Änderung)

my $no_cache = 1;

was aber bedeutet, dass nun überhaupt kein Cache mehr existiert beziehungsweise genutzt wird. Das sollte er aber, wenn nicht nur XML-Dokumente auszuliefern sind, die wechselnde Query-Strings beinhalten. Der Ausweg war ein Hack; schließlich musste es schnell gehen. Zusätzlich zu den von AxKit vorgesehenen Direktiven, die in der httpd.conf nutzbar sind, sorgten Ergänzungen in den Dateien AxKit.pm, Cache.pm sowie ConfigReader.pm dafür, dass die zusätzliche Anweisung AxNoCaching innerhalb einer Location einsetzbar ist und darüber entscheidet, ob der Cache zum Tragen kommt oder nicht. Der Schwierigkeitsgrad dieser ‘Übung’ hielt sich in Grenzen: mit Rückversicherung beim lokalen Haupt-Perlianer kann nichts schief gehen ...

Die folgenden Zeilen aus der httpd.conf legen für zwei unterschiedliche Verzeichnisse die AxKit-Konfiguration fest:

<Location /xslt/dict>
SetHandler perl-script
PerlHandler AxKit
PerlSetVar AxNoCaching 1
PerlSetVar AxTranslateOutput 1
PerlSetVar AxOutputCharset ISO-8859-1
...
</Location>
<Location /xslt/brief>
SetHandler perl-script
PerlHandler AxKit
AxCacheDir /wo/auch/immer/axkit_cache
PerlSetVar AxTranslateOutput 1
PerlSetVar AxOutputCharset ISO-8859-1
...
</Location>

Für das Briefeverzeichnis ist der Cache jetzt aktiviert, fürs Wörterbuch nicht. Die beiden jeweils letzten Zeilen vor der Auslassung waren deshalb zwingend, weil AxKit eigentlich UTF-8 verwendet und nur diese Eintragungen den europäischen Zeichensatz (Umlaute et cetera) gewährleisteten. Die Angabe encoding="ISO-8859-1" innerhalb des jeweiligen Stylesheet nutzte da nichts.

Mehr Infos

Betrifft: Labor-Alltag

Diese Serie soll jeweils aktuelle Artikelprojekte begleiten, indem hier Installationshürden, Kompilierorgien und Nachbereitungsfeste dokumentiert werden sollen. Natürlich möglichst so, dass diejenigen, die auf ähnliche Hindernisse stoßen, sie mit etwas mehr Schwung uind Leichtigkeit aus dem Wege räumen können. Fraglich ist, ob das immer (so leicht und in dieser Kürze) möglich sein wird ...

(hb)