Wie Ihr wißt, stehe ich dem Versenken von Daten in Datenbanken eher skeptisch gegenüber, ich halte das (UNIX-) Filesystem noch immer für die sicherste Datenbank der Welt, die für die meisten (nicht Enterprise-) Anwendungen auch hinreichend schnell ist. Daher sollte ich dieser Liste meine besondere Beachtung schenken: A list of XML based CMS for Web Developers. Speziell Kumera erfreut den alten Perl-Hacker in mir. [Noch einmal Peter van I. per Email.]
Die tägliche Ration Wahnsinn — seit April 2000 im Netz
Über …
Der Schockwellenreiter ist seit dem 24. April 2000 das Weblog von Jörg Kantel (Neuköllner, EDV-Leiter, Autor, Netzaktivist und Hundesportler — Reihenfolge rein zufällig). Hier steht, was mir gefällt. Wem es nicht gefällt, der braucht ja nicht mitzulesen. Wer aber mitliest, ist herzlich willkommen und eingeladen, mitzudiskutieren!
Die Inhalte des Schockwellenreiters stehen unter einer Creative-Commons-Lizenz.-
Werbung
-
Soziales
Klickr Flickr
Neu in meinem Wiki
Wobei es durchaus Argumente gegen den Einsatz von XML in CMS gibt.
Auf den ersten Blick mag XML für ein CMS charmant sein – aber auch nur, wenn das CMS sehr einfach bleibt. Aus XML per XSLT einfach HTML erzeugen klingt nett, aber:
- Ein CMS ist nicht nur eine Ansammlung von Seiten. Eine Webseite ist ein in sich verlinktes Projekt, welches jederzeit konsistent sein muss. Das bietet XML keinerlei Mechanismen.
- Das Parsen von XML ist langsam, d.h. ein Caching-Mechanismus ist unabdingbar.
Beispiel: Eine Seite A wird unbenannt. Jetzt müssen in allen XML-Dateien alle Verweise auf Seite A geändert werden. Daher bietet es sich an, eine ID für jede Seite zu hinterlegen. Diese in den XML-Dateien zu speichern, wäre genauso schlimm. An den INode sollte man besser garnicht erst denken (Backups, Plattformunabhängigkeit). Wenn man dann noch Konzepte wie Mehrsprachigkeit und verschiedene Ausgabetemplates pro Seite umsetzen will, stößt man bei XML schnell an die Grenze.
Als ich vor Jahren mit der Programmierung meines CMS begann, benutzte ich in der Tat auch XML-Dateien im Dateisystem. Es war vor allem langsam und die Programmierung wurde aus o.g. Gründen schnell kompliziet. Mittlerweile gibt es ein Datenmodell, XML wird an keiner Stelle mehr benötigt.
Es ist auch falsch zu sagen, dass man Daten in Datenbanken versenkt, denn Datenbanken sind genau für diesen Zweck geschaffen worden. Wichtig ist nur ein einfaches und durchschaubares Datenmodell. Wenn man von “Versenken” spricht, dann eher bei XML – ein falsches Zeichen, und die Datei ist nicht mehr parsbar – die SQL-Datenbank funktioniert immer. Und SQL ist nun wirklich kein Hexenwerk
Das ist nicht das Problem: Mein Hauptkritikpunkt ist der, daß in einer Datenbank die Daten nicht mehr in einem von Menschen lesbaren Format vorliegen. Und glaube mir, ich mache EDV schon einige Jahrzehnte — es kommt vor, daß DB-Hersteller pleite gehen. (Ich habe zum Beispiel heute noch einen DB-Dump der ersten zwei Jahre des Schockwellenreiters (2000 und 2001) den ich zwar theoretisch — ich kenne das Datenformat — auslesen könnte, praktisch macht das aber ziemlich viel Mühe.)
Mit XML (oder von mir aus auch YAML oder JSON) ist man da auf einer sicheren Seite. Und natürlich hast Du Recht — ein Caching-Mechanismus ist da unabdingbar. Mein Wiki speichert Textdateien, indiziert und chached ziemlich intelligent und die Geschwindigkeit ist annehmbar.
Aber da bei einem CMS eigentlich sowieso zwischen Redaktions- und Produktionsserver getrennt werden sollte, macht das keinen Unterschied. Im Regelfalle greifen auf den Redaktionsserver nur wenige Leute zu, so daß ein XML-basiertes CMS vertretbar ist. Und der Produktionsserver besteht sowieso aus mehrheitlich statischen HTML-Seiten und einem Webserver, wobei dynamische Elemente entweder per Webservice eingebunden oder von einer (abgespeckten) Version des Redaktionsservers ausgeliefert werden. Viele Enterprise-CMS (z.B. Fiona) arbeiten so.
Hi Jörg,
Und dank ANSI-SQL standardisiert.
natürlich speichert jedes RDBMS die Daten intern(!) in einem eigenen binären Format. Es soll sogar DBs geben, die garnicht das Dateisystem verwenden, sondern direkt auf die Plattenpartition zugreifen. Aber: Das ist eigentlich völlig egal, denn es gibt SQL, das jedes (naja fast jedes, sogar SQ-Lite) beherscht. Einfach einen Dump ziehen und in die nächste Wunsch-DB importieren. Und SQL ist definitiv “Menschen-lesbar”
Ich wollte nur sagen, dass XML-Dateien für komplexe CMS ungeeignet sind, alleine aufgrund der zu gewährleistenden Konsistenz. Wenn ich Seite A lösche/verschiebe, muss auch der Link in Seite B auf Seite A angepasst werden. Mit DB-Mitteln wie z.B. foreign-keys kein Problem. Ich habe nicht umsonst mein CMS von XML-Dateien auf RDBMS umgestellt – und habe es nicht bereut
Bei der Trennung von Redaktion- und Liveserver hast Du natürlich recht – auch wenn das nicht immer trivial ist, z.B. bei dynamischen Inhalten, Formularen etc.
Aber ich bin großer Fan von Statifizierung
Theorie: Ja! Praxis: Hast Du mal einen Dump von MySQL nach PostgreSQL importiert? Na bitte.
Und es soll außerdem noch vielgenutzte Datenbanken geben, die nicht wirklich SQL können (FileMaker ist bei mir im Job mein Problemfall, alte DBase-Dateien (obwohl wenigstens ASCII) lassen einen oft graue Haare wachsen, sind aber im GIS-Umfeld heute noch weit verbreitet, etc.), von LISP- und PROLOG-Archiven will ich erst gar nicht reden.
Und wenn wir das wissenschaftliche Umfeld verlassen, dann erinnere ich nur an COBOL. Das sind meist selbstgestrickte RDBMS aus einer Zeit vor SQL. Und wer garantiert mir, daß es nicht auch eine Zeit nach SQL geben wird?
http::/www.schockwellenreiter.de ein lahmer Kriecher. Ja, der Schockwellenreiter ist ein lahmer Kriecher geworden. Vor allem wenn ich zum Beispiel http://www.schockwellenreiter.de angesurft hatte (ja, ich lese keine RSS feeds) und dann via einer Verlinkung – wie hier in den Kommentaren – zum Beispiel bei http://www.jandankert.de/ lande. Wenn ich danach in meinem Firefox die grüne Pfeiltaste (go back one page) klicke und zurück zum Schockwellenreiter will, dann kommt das einer Vollbremsung gleich. Es braucht ewig um die Schockwellenreiter Seite aufzubauen. Offenbar wird nichts gecached.
Die Ladezeiten stelle ich mir ungefähr so vor wie die von http://blog.fefe.de dem Weltmeister und Weltrekordhalter was die Ladezeit einer Webseite betrifft. Link anklicken und die Webseite wurde vom Browser geladen. So soll es sein. Das wäre übrigens mit xslt und xml wunderbar zu realisieren, was der fefe aber nicht nutzt.
[...] Andreas, ich benutze sowas nicht. Es soll wohl auch einige praktische Schwierigkeiten geben, wie CMS und XML – Der Schockwellenreiter dazu schreibt. Andererseits scheint es auch zu gehen: XML based CMS mit XSL und XSLT in der [...]