Immer frisch – der reieRMeister im Abo als Atom-Feed:
―8. Juli 2009
Nachdem jetzt der ein oder andere mitbekommen hat, dass ich mein Design ein wenig umgestellt habe – von einigen kritisiert, von anderen gelobt – wollte ich kurz erklären, was hier wirklich passiert ist. Das geänderte Design ist nämlich nur der kleinste Teil des Umsturzes. Hallo Welt, diese Seite wird nun komplett aus XML erzeugt und ausgeliefert!
Bevor jetzt irgendein Schlaumeier meint, dass XHTML2 ja gerade mit warmem Torf bedeckt wurde und ich ja so aufs falsche Pferd gesetzt habe – dem schleudere ich nur keck entgegen: Denkste! Denn auch HTML5 wird, wenn es denn mal einsatzbereit ist, eine Text- und eine XML-Serialisierung erlauben. Das einzige, was ich dann noch zu tun habe, ist, die Doctype Declaration zu entfernen (bzw. für die text/html-Ausgabe die auf die Barebone-Variante laut HTML5-Spezifikation einzudampfen). Und dann kann ich anfangen die wirklich interessanten Teile von HTML5 zu nutzen.
Dieser Webauftritt bezieht seine Daten jetzt aus einer XML-Datei, in der die Inhalte aller Seiten stehen. Vorher hatte ich die Inhalte in einzelnen PHP-Dateien zu stehen. Das machte die Aktualisierung bei zunehmendem Inhaltsvolumen leider immer unhandlicher. So musste ich zum Beispiel die Newsfeeds immer manuell aktualiseren.
Wenn heute ein user agent auf meiner Seite aufschlägt, nimmt ein kleines PHP-Skript dessen Request auseinander, rät, was er wohl haben mag (dem IE beispielsweise liefere ich nach wie vor die Seite mit einem text/html-MIME-Type aus) und stößt mit ein paar Parameteren eine XSL-Transformation (über die libxslt-Bibliothek, die bei PHP5 dabei ist) an, die dann die HTML-Ausgabe des Inhalts der jeweiligen Seite auswirft.
Das ganze sieht wird in PHP5 grob so angestoßen:
$oXmldoc = DOMDocument::load("file.xml"); // die XML-Datei laden
$oXsldoc = DOMDocument::load("styleheet.xsl"); // das XSL-Stylesheet laden
$oXslproc = new XsltProcessor(); // das XSLT-Prozessor-Objekt erzeugen
$oXslproc->registerPhpFunctions(); // PHP-Funktionen im XSL ermöglichen
// (nettes Zeug aber nicht unbedingt nötig)
$oXslproc->setParameter(NULL, "sVariable1", $sVariable1); // die Variable
// $sVariable1 als Parameter an das Stylesheet durchreichen
$oXslproc->importStylesheet($oXsldoc); // das Stylesheet ins
// XSLT-Prozessor-Objekt importieren
$sXhtmldoc = $oXslproc->transformToXML($oXmldoc); // die Transformation anwerfen
echo $sXhtmldoc; // das Resultat ausgebenNatürlich gab es ein paar Fallstricke zu überwinden. So wirft libsxlt bei einer Transformation zu HTML auch immer ein meta-Element für den Content-Type text/html mit aus. Den sollte man nachträglich mit PHP per str_replace durch den korrekten Wert ersetzen.
Um im XSL-Stylesheet auf den übergebenen Parameter sVariable1 zugreifen zu können, braucht es im Stylesheet die Angabe <xsl:param name="sVariable1"/> als Top-Level Element.
Da ich jetzt alle Inhalte an einer Stelle habe und sie einheitlich mit relativ einfachen Mitteln in so ziemlich alles umtransformieren kann, was aus Text besteht, kann ich jetzt ziemlich schnell unterschiedliche Repräsentationen meines Inhalts mit einem einheitlichen Verfahren bereitstellen. Sei es, dass ich eine Google-Sitemap bereitstellen möchte oder einen Newsfeed. Und da es sich bei solchen Formaten ja meist um XML handelt, muss ich mir nur wenige Gedanken um das Zusammensetzen der Ausgabeformate machen. Immer wenn ein neues Format benötigt wird, schreibe ich einfach ein neues Stylesheet.
Ein weiterer positiver Nebeneffekt: die Ausgabe ist immer well formed und kein Browser stirbt mehr den yellow screen of death.
Vielleicht. Aber dazu hätte ich besser SQL lernen müssen. Und, nun ja, da ich XSLT schon ganz gut kann, war das der Weg, den ich gegangen bin.
Okay. Ich war vielleicht auch etwas faul. Aber ich wollte das schon immer mal ausprobieren.
Im Nachhinein fand ich es sehr interessant, wie sehr mein internes XML-Format dem Atom-Format ähnelt. Offenbar haben sich die Schöpfer dieses Formats die richtigen Gedanken gemacht.