Über diese Blog-Software

Es gibt mittlerweile zigtausend unterschiedliche Webapplikationen für das Erstellen eines Blogs (eine kleine Auswahl der bekannteren kann z.B. auf Wikipedia gefunden werden). Höchstwahrscheinlich hat das damit zu tun, dass das Grundprinzip so bestechend simpel ist: es gibt eigentlich nur Posts und Kommentare, und die einzigen wirklich unabdingbaren Views auf diese Grundelemente sind eine Liste aller Posts und ein einzelner Post inklusive Kommentare. Eine solche Blogsoftware mit den grundlegenden Funktionen selbst "from scratch" zu entwickeln verspricht daher eine einfache Aufgabe zu sein, ein dankbares kleines Projekt für die Erkundung von beispielsweise einer neuen Programmiersprache - könnte man meinen ;-)

Die Software für dieses Blog ist aus genau diesem Grund entstanden. Sie diente (oder vielmehr: dient) mir dazu, mich eingehender mit der Programmiersprache Ruby und dem Web-Framework Rails vertraut zu machen - vor allem Letzteres stand schon recht lang auf meiner "könnte interessant sein"-Liste. Und ja, es war tatsächlich interessant. Auch wenn ich Ruby on Rails sicherlich nicht für die beste Wahl bei jedem möglichen Webprojekt und schon gar nicht für der Weisheit letzter Schluss halte, bin ich ziemlich beeindruckt von der Effizienz des Frameworks: mit nur ein paar Zeilen Code erreicht man oft Dinge, die in anderen Frameworks/Sprachen (etwa Java EE oder PHP) ein Vielfaches an Code erfordern. Typische CRUD-basierte Anwendungskomponenten erzeugt Ruby on Rails sogar vollautomatisch per Generator - das sogenannte Scaffolding macht's möglich!

Das Schöne daran: man kommt sehr schnell zu ersten Ergebnissen; eine grundlegende Basis für eine neue Anwendung steht in wahnsinnigem Tempo und kann anschließend zur eigentlichen Applikation ausgebaut werden. Jedoch merkt man spätestens an diesem Punkt, dass auch Ruby on Rails in keinster Weise etwas mit Magie zu tun hat: trotz aller Hilfen und Tools muss auch in Ruby die Geschäftslogik einer Anwendung ganz normal von Hand implementiert werden. Und wenn man sich dabei einmal aus welchen Gründen auch immer dazu entscheidet, einen anderen als den vom Framework "vorgetrampelten" Weg zu beschreiten, steht man auch in Ruby on Rails genauso schlecht (oder gut) da wie in jedem anderen Web-Framework - wenn nicht sogar schlechter, weil man in solchen Fällen gelegentlich auch mal gegen das Framework ankämpfen muss. Es gilt also auch hier: wo Licht ist (und Ruby on Rails leuchtet definitiv stellenweise sehr hell) ist auch Schatten - und man sollte sich, wenn es um die Entscheidung für oder gegen die Anwendung eines bestimmten Frameworks in einem Projekt geht, definitiv weder von irgendeinem Hype wie dem, der seit einigen Jahren um Ruby on Rails veranstaltet wird, noch vom vermeintlichen Totschlagargument "das-haben-wir-schon-immer-so-gemacht" blenden lassen.

Aber zurück zum Thema: in knapp zwei Wochen sind die Grundfunktionen dieses Blogs entstanden. Postings lesen, schreiben, chronologisch auflisten, eine Trennung von Admin- und User-Sicht, Kommentarfunktionen, ein chronologisches Archiv und ein sehr simpel gehaltenes Mini-CMS für statische Seiten (wie diese hier) - alles inklusive Layout und Design, auch bei Teilen, die lediglich der Admin zu Gesicht bekommt. Sicher hätte ein erfahrener Ruby-Entwickler, der sich nicht wie ich während der Entwicklung in ein völlig neues Framework (na ja, fast völlig neu - in einer Art kleinem, aber gut gestalteten Workshop, der Teil einer Webentwicklungs-Veranstaltung an meiner Hochschule war, konnte ich immerhin schon ein paar erste Schritte mit Ruby on Rails machen) hätte einarbeiten müssen das Ganze sogar in der Hälfte der Zeit geschafft - oder in derselben Zeit noch einige der Features implementiert, die ich hier in Zukunft noch einbauen möchte, z.B. Tags zur Kategorisierung von Postings oder (ganz wichtig!) RSS-Feed-Generierung. Nichtsdestotrotz ging das Entwickeln auch für mich als Neuling recht flott und weitgehend ohne Frustmomente voran, und das, obwohl ich gleichzeitig noch eine weitere, auch eher neue und unbekannte "Web-Technologie" angewendet habe...

Worum es geht? Man sehe sich mal den Code dieser Seite im Browser an :o). Komische HTML-Tags, oder? <page> und <contentpage> gehören genausowenig zum HTML-Vokabular wie diese Blog-Software HTML-Seiten ausliefert! Eigentlich liefert sie nämlich nur XML-Dokumente, die bis auf die Layoutinformationen in einem konkreten Posting oder Kommentar keinerlei Angaben enthält, wie die enthaltenen Informationen dargestellt werden sollen. Header, Footer, die ganze Hölle von verschachtelten <div>s, mit der man sich im tabellenlosen Layout rumschlagen muss, von alldem steckt nichts in den dynamisch erstellten XML-Dokumenten. Stattdessen findet sich ganz oben ein Verweis auf - ein XSLT-Stylesheet!

Es ist zwar ein eher unbekannter Fakt, aber es ist Fakt: praktisch alle modernen Browser - Opera (mein persönlicher Favorit), Firefox, Safari und der IE - enthalten in ihren aktuellen Versionen eine vollständige XSLT-Transformationsengine. Und das ist eine ziemlich coole Sache, denn damit kann man als Webentwickler das Erstellen des eigentlichen HTML-Codes (oder besser gesagt: XHTML-Code) in den Browser des Users verlagern. Dieser Ansatz hat eine ganze Reihe praktischer Vorteile:

• Dadurch, dass nur der eigentliche Seiteninhalt - plus minimalem XML-Overhead - vom Server ausgeliefert werden muss, reduziert sich die Download-Größe einer einzelnen Website deutlich. Natürlich muss das Stylesheet mindestens einmal übertragen werden. Bei einer vernünftigen Konfiguration der Cache-Header kann dieses aber bei allen Folgeseiten aus dem Cache des Browsers bezogen werden und muss tatsächlich nur einmal pro Seitenbesuch über die Leitung wandern.
• Sauberes, wohlstrukturiertes XML ist ideal für die Weiterverarbeitung von Daten durch andere Anwendungen. Heutzutage basieren viele Web- oder Desktopanwendungen auf dem Abruf von Daten per HTTP - nicht selten werden dabei eigentlich für die Darstellung im Browser gedachte HTML-Seiten geparsed, weil die fragliche Website kein echtes Interface für die Abfrage von Daten durch Anwendungen besitzt. Dieses Scraping ist sowohl ineffizient als auch fehleranfällig: die ganzen Layout-Informationen werden bei der Maschine-zu-Maschine-Kommunikation in der Regel überflüssigerweise übertragen, und jede kleine Änderung an der Struktur der HTML-Seite kann Anpassungen im Code der Scraping-Anwendung erforderlich machen. Wenn die Anwendung stattdessen XML ausspuckt, das zur Anzeige durch XSLT nach XHTML transformiert wird, ist die Anwendungs-Schnittstelle quasi eingebaut: ruft ein Programm eine solche Seite ab, ignoriert es einfach das Stylesheet und stürzt sich stattdessen auf die XML-Daten.
• Die Lokalisierung einer Webanwendung wird durch XSLT enorm vereinfacht. Es ist beispielsweise möglich, alle statischen Strings, die vom Stylesheet eingefügt werden, in eine XML-Datei auszulagern, welche im Stylesheet ausgelesen wird. Die Einbindung der String-Datei kann sogar parametrisiert erfolgen: ein Parameter im ausgelieferten XML-Dokument steuert dann, in welcher Sprache die Seite letztlich im Browser dargestellt wird. Die Umschaltung der Sprache erfordert dann im Optimalfall nur das Ändern eines einzigen XML-Attributs! (Okay, man muss fairerweise anmerken, dass die Anwendung sich um Strings, die sie im XML-Dokument ausliefert, selbst kümmern muss; dasselbe gilt für andere länderspezifische Dinge wie Datumsformate)

Gut, der XSLT-Transformations-Ansatz hat auch einen Hauptnachteil, den man unbedingt berücksichtigen sollte: Eine XSLT-basierte Seite kann natürlich nur von einem Browser, der XSLT-Transformationen beherrscht, überhaupt dargestellt werden. Ohne XSLT sieht ein Browser nur ihm völlig unbekannte Tags - dabei kann kaum etwas Vernünftiges entstehen.

Aber: es gibt eine Lösung für dieses Problem! Nichts hindert einen Webserver daran, den übermittelten User-Agent auszuwerten und die XML-Antwortseite vor der Auslieferung an einen Browser, der nicht zweifelsfrei als XSLT-fähig einzustufen ist, durch eine serverseitige XSLT-Engine in valides XHTML zu transformieren. Damit sind alle bedient: moderne Clients sehen schlanke XML-Seiten und transformieren sie selbst, alte Clients erhalten XHTML wie bei jeder anderen Webanwendung auch, und bei der Maschine-zu-Maschine-Kommunikation setzt die anfragende Software einfach einen passenden User-Agent-Header und erhält die XML-Daten.

Die XSLT-Transformation auf Serverseite ist in diesem Blog mittlerweile auch umgesetzt; die Details zur Umsetzung können im passenden Posting dazu nachgelesen werden. Damit wär der Hauptnachteil von XSLT praktisch bezwungen. Nun hat das Blog eigentlich nur noch einen architektonischen Schönheitsfehler: es finden sich bei mir in den Controller-Sourcen noch ein paar hartkodierte Textstrings, die da eigentlich nicht reingehören, wenn man es mit der sprachspezifischen Auslagerung von Strings in eine externe XML-Datei ernst meint. In Zukunft wird sich das aber sicher noch ändern :)

By the way: ich persönlich wurde durch die World of Warcraft Armory auf diese Technik aufmerksam. Die WoW-Armory eignet sich wunderbar als leuchtendes Beispiel für die damit verbundenen Vorteile: Trotz der ziemlich umfangreichen grafischen Ausgestaltung der Seiten laden diese auf dem Firefox (der einzige Browser, den die Armory mit XML+XSLT bedient; alle anderen Browser werden aus irgendeinem Grund trotz ihrer XSLT-Fähigkeiten auch in den aktuellen Versionen mit XHTML versorgt) flott, die gesamte Anwendung ist durch in separate XML-Dateien ausgelagerte Strings mehrsprachig verfügbar und das Auslesen von Daten durch Drittanwendungen klappt einfach und problemlos. Letzteres beweisen die vielen auf Armory-Daten basierenden Drittanwendungen, die mittlerweile existieren - aber das führt nun eigentlich zu weit in WoW-spezifisches Territorium ;-)


Es ist zwar noch ein recht löchriges und unvollständiges Projekt, aber falls sich ein Entwickler für den Sourcecode interessieren sollte:

https://anonymous:anonymous@firehead.de/repositories/FireBlog

Die Software ist ausdrücklich nicht für den produktiven Einsatz gedacht, es sind einige für dieses Blog spezifische Komponenten im Repository (wie das komplette Design etwa), es gibt keinerlei Installationsroutinen oder Komfortfunktionen für die Einrichtung, keinen Support und ich übernehme keine Haftung für jegliche Folgen des Einsatzes. Das ist allerdings nicht als Verbot zu verstehen ;-) macht mit dem Code was ihr wollt, nur ein Verkauf oder die Verwendung von Bestandteilen in kommerziellen Produkten sind explizit untersagt.

Dieses Weblog wird betrieben mit FireBlog v0.1 | Impressum