auch schlafen ist eine form der kritik

Systematisch schwerer

ben ist inzwischen HTML-statisch mit seinem Heimweh_ unterwegs.
Konstantin seit kurzem txt-statisch mit seinem Blogracer.
Beide jeweils (mehr oder weniger) mit einem Schuß PHP und Javascript.

Spätestens jetzt fühlt sich mein Drupal hier ungleich schwerer an. Der Quellcode ist – bei über 200 000 Zeilen auch nicht weiter verwunderlich – ganz und gar nicht Oberfläche, sondern ein weiterhin zu be- und durchschreitendes Dickicht. Konstantins „Umstieg“ hat das ohnehin vorhandene Kribbeln in den Fingern nicht gerade beruhigen können, so dass ich mich in der kommenden Zeit dilettantisch ebenso an etwas leichterem versuchen werde. Mal schauen, was dabei herauskommt, ob überhaupt etwas herauskommen wird. Offenes Ende also. Vielleicht führt das Rumprobieren irgendwann zu einem Wechsel oder es versinkt geradewegs ins nichts. Wer weiß das schon.

Momentan schwirren folgende Überlegungen wirr im Kopf umher:

Für die Ablage der Daten und deren Datierung benutzt ben im Heimweh eine entsprechende Ordnerstruktur (Jahr, Monat, Tag), während Konstantin die Textdateien (wie es nach außen hin den Anschein macht, man möge mich berichtigen) in einen einzigen Ordner pro Jahr packt. bens Ansatz erscheint mir für meinen eigenen Versuch vorteilhafter. Unter anderem allein schon der immanenten Eindeutigkeit der Hierarchie wegen.

Während für ben HTML – der Quellcode – Oberfläche ist, setzt Konstantin wie erwähnt auf txt-Dateien für seine Einträge. „Ich will meinen geschriebenen Text immer noch sehen und lesen können, ohne HTML-Code.“ Dazu würde ich auch tendieren. Der Quellcode ist im Heimweh-System wirklich Oberfläche, das aber nur auf jener programmatischen Ebene. Dabei geht es, so würde ich meinen, doch gerade darum den Abstand Schreiber-System-Text zu verringern. Konstantins Ansatz konzentriert sich damit in gewisser Weise stärker auf die eigentlichen Texte und verkürzt jene Entfernung. Das hat seinen Reiz, damit könnte ich mich gut anfreunden. Klar ist aber auch, dass in der Hinsicht doch ein wenig „geschummelt“ wird, der Text mittels Markdown ebenso mit (minimalem) Markup versehen wird und irgendwie in die Seite gepumpt werden muss. Das Markup-„Problem“ reinen Textes lässt sich nicht vermeiden und ich frage mich, ob ben_s Ansatz trotz der HTML-„Oberfläche“ damit letztlich nicht doch konsequenter ist. Hm.

Was den semantischen Teil des Ganzen betrifft, bin ich auf der faulen Seite. Händisches Anlegen aller Schlagworte bzw. Begriffe und manuelles Verlinken würde ich mir im Gegensatz zu ben_ gerne sparen. Einzig für Begriffsdefinitionen oder ausladendere Termseiten würde ich mir das vorbehalten. Konstantin stellt die Metadaten in der *.txt dem eigentlichen Text voran. Davon ausgehend könnte man sich mittels PHP etwas zusammenbasteln. Wie auch immer, würde es ohnehin auf ein Ausdünnen der momentan vorhandenen Begriffe hinauslaufen, was ansich nur von Vorteil sein kann. Minimalismus fokusiert.

In meiner Vorstellung würde es bisher bei mir also auf einen Hybriden beider Ansätze hinauslaufen: Schlichte txt-Dateien für „normale“ Einträge, d.h. solche, die sich makrotypografisch im Rahmen halten bzw. keiner wirklichen Auszeichnung bedürfen. Darüberhinaus jedoch ebenso die Fähigkeit/Möglichkeit stattdessen normale HTML-Dateien in einen Ordner stecken zu können. Denn auch wenn mich wie ben_ der Gedanke an statische Zeitlosigkeit (ältere Einträge erscheinen zwangsläufig im Gewand der Aufmachung zu jenem Zeitpunkt) in Hinblick auf die gesamte Aufmachung des Blogs reizt, so würde ich doch in diesem Kontext (ohje!) Einheitlichkeit bevorzugen. Allein aus Gewöhnung. Mit dieser vorhandenen Möglichkeit wäre auch der Punkt gestaltete Einträge in einem txt-System gegessen.

Mir ist klar, dass bei einer Hybridisierung beider Ansätze die ihnen je innewohnende Konsequenz sicherlich verwischt werden wird, aber hey – das macht den Reiz aus und ist aufgrund der Tatsache, dass ich kein Coder oder auch nur guter Denker bin, wenigstens so konsequent. The best of both worlds… or surely the worst of them in combination.

Wie geschrieben, kommt vielleicht oder mit Sicherheit nichts Brauchbares heraus. Aber darum geht es auch gar nicht. Intrinsisches Probieren und Versuchen ist sich selbst ausreichender Grund und Rechtfertigung.


9 Antworten

  1. ben_s Ansatz lässt mich auch nicht los. Glücklicherweise habe ich den Vorteil, dass ich noch kein Jahrelang in Betrieb befindliches System umstellen muss, sondern bei Null anfangen kann.

    Deshalb arbeite ich gerade an einer allgemeiner gehaltenen Lösung. Mein System ist aber leider momentan noch so stark in Entwicklung, dass ich momentan noch keinen Wechsel empfehlen würde. Rein schauen kannst du ja trotzdem mal.

    Das ganze geht eher in Richtung von ben_ als in Richtung von Konstantin. Es werden statische HTML Seiten verwendet, die mit normalem PHP-Code beliebig aufgepeppt werden können. Außerdem sollen sich bald automatisch Indizes erstellen lassen (die Funktion ist schon fast fertig), deren Inhalt in normalen Text-Dateien gespeichert wird und dann zu beliebigen Zusammenfassungen umgewandelt werden können. Kommentare gehen schon, Feeds müssen noch folgen.

    Markdown-Support hatte ich schon mal für Kommentare drin, der fremde Code war mir aber zu aufgebläht.

    Hoffentlich macht es nichts, wenn ich hier ein wenig Werbung mache.

  2. Fym, auf diesen Artikel habe ich schon seit Längerem gewartet 🙂 Mein Senf dazu:

    – Ordnerstruktur ist in Blogracer genau so möglich. Du bestimmst bei Blogracer nur, in welchem Ordner die ganzen Blogeinträge liegen. Alles andere sucht sich Blogracer selbst raus. Einschränkung: ein Artikelname (bzw. url) darf nicht zwei mal vorkommen (z.B. „systematisch-schwerer“). Damit benutze ich diese Namen als IDs. Die Ordnerstruktur nach Datum hat noch einen großen Vorteil: Bei Suche oder Listen von Einträgen kommt die zeitliche Sortierung automatisch.

    – In die .txt-Dateien lässt sich beliebiger HTML-Code einfügen. Damit geht schon einiges an Gestaltung, auch wenn es keinesfalls zu vergleichen ist mit _echten_ statischen HTML-Seiten. Ich hab für Blogracer angedacht echtes HTML durchzuschleusen, hab’s aber noch nicht programmiert. Zu faul.

    – Semantik: ich schreibe Terms in einen Artikel in eine Zeile hintereinander. Alles andere (Übersichtsseiten von Terms, Verlinkung) macht das System selbst. Sollte ein Term auch eine Definitions-TXT haben, wird diese mitgerendert (dann wird aus einem „Schlagwort“ ein „Thema“ an der Oberfläche). Es gibt bei mir keine statischen Artikellisten zu einem Term, noch gibt es statische Dateien zu Terms ohne Definition. Den Grund hast Du ja schon genannt: möglichst wenig Pflegeaufwand, bitte.

    – Hybrid: finde ich legitim. Wollte ich ja auch, s.o.

    Habe es übrigens immer noch nicht geschafft, Git bei mir zu installieren. Du kriegst den Quelltext von Blogracer gleich per E-Mail.

  3. fym

    Danke euch beiden! Die Ansätzen werden sicherlich die ein oder andere Anregung geben.

    Bei den bisherigen ersten Gehversuchen merkte ich schon:
    a) Ich hätte um mod_rewrite nicht immer so einen großen Bogen machen bzw. es dem jeweiligen CMS überlassen sollen. Das rächt sich jetzt mitunter hin und wieder.
    b) Ein PHP-Unterbau muss sein (und auch ben_ kommt ja trotz aller statischen Dateien nicht so wirklich drumrum), auch wenn darüber immer die Gefahr der Codemasse schwebt. Ich muss mir stets vor Augen halten, dass es ja gerade um Minimalismus und Code-Überblick geht. Gerade weil die explizite Nutzung und Bejahung von PHP häufiger Gedanken an modularen Aufbau und anderen „Features“ anzieht. Diese Anflüge muss ich bewusst ersticken.
    c) Templates sind mir doch wichtiger, als ich dachte. Oder vielmehr: die Trennung von Markup und Programmlogik. Ich schleuse lieber ein paar mit entsprechenden Markern versehene HTML-Dateien durchs System, wenn ich dafür nur diese Trennung erhalten kann. In dem Zusammenhang nehme ich auch eventuellen zusätzlichen Code in Kauf. (Im Prinzip schaue ich da von mir selbst ab, weil das igA-Modul hier momentan ebenso mit htmlisierten igAs verfährt.)
    d) Meine PHP-Kenntnisse könnten viel besser sein 😉

    @Paul: Von Markdown sehe ich momentan auch ab. Nicht wegen der Nutzung, die ist tatsächlich recht minimal. Eher von der Codemenge her. Als ich in die markdown.php reingeschaut habe – ne, das ist ja genau das Gegenteil dessen, was ich will. Das muss unter Erhalt der rudimentärsten Funktionen auch code-leichter gehen.

    @Konstantin: Wenn man bei dir auch genauso gut HTML in die txt schreiben könnte, negierte das ggf. nicht den Sinn (Lesbarkeit des Textes ect.) ihrer Verwendung, so man sich denn irgendwann dazu hinreißen ließe?

  4. HTML in Textdateien: ja richtig, am besten ohne. Aber manchmal willst Du etwas darstellen (z.B. irgend eine krude Anordnung an Bildern), die Du nicht per Markdown oder ähnlichem darstellen kannst. Das ist so ein Ausnahmefall, da finde ich HTML nicht verkehrt.

    Ich komme ja schon deswegen nicht in die Versuchung, HTML in die Textdateien zu schreiben, weil ich schlicht zu faul bin.

  5. mod_rewrite kann ein ganz schöner Zeitfresser sein. Es hat mich schon einige Stunden Lebenszeit gekostet. Trotzdem bilde ich mir ein, jetzt eine ziemlich robuste .htaccess-Datei für alle Lebenslagen zu haben.

    Auch der restliche Code ist ziemlich kompakt, wenn man sich nur meinen grundlegenden PHP-Unterbau ansieht. Alles Wichtige passiert steht im Prinzip in diesen drei Dateien:

    • public/manager.php ist quasi der Einstiegspunkt für den Besucher und implementiert die Logik, mit der die entsprechende HTML-Datei geladen wird.
    • lib/functions.php stellt ein paar grundlegende Funktionen zur Verfügung, wie das Einbinden einer HTML-Datei oder einen HTTP-Redirect.
    • lib/conf.php bietet die Möglichkeit ein paar Konfigurationen vorzunehmen.

    Das typische URL-Schema ist domain.com/dir1/dir2/file bzw. domain.com/dir1/dir2/ für Ordner (genauer: deren index.html). Die HTML-Dateien liegen dann im Verzeichnis public/, welches gleichzeitig Wurzelverzeichnis des HTTP-Servers ist und somit sind PHP-Dateien in lib/ vor Zugriff von außen geschützt.

    Alles in allem habe ich somit ca. 150 Zeilen Code (ohne die ganzen PHPDoc Kommentare und inklusive .htaccess), die schöne URLs können, automatisch die URL fixen, falls ein ‚/‘ vergessen wurde o.ä. und auch auf eine 404-Seite redirecten können, sollte eine URL nicht existieren.

  6. fym

    mod_rewrite war(/ist) für mich wohl vor allem deshalb ein Krampf, weil aufgrund meiner verwendeten Ordnerstruktur noch mit potentiellen Anfragen a la „/2010/11/06/“ umgegangen werden muss. Zumindest lokal läuft es wenigstens so, wie ich es momentan brauche. Das kann hier auf dem Webspace allerdings wieder anders ausschauen.

    Derzeitiger Stand:
    Das Format der Textdateien schaut wie bei Konstantin aus. Die ersten 3 Zeilen beinhalten Meta-Krams (Titel, Titelslug, Terms), danach kommt der eigentliche Text und eventuelle Kommentare kommen darunter. Das Grundgerüst steht insofern, als das txt’s in entsprechend benamste Unterordner gesteckt werden können. Seiten kommen in einen einzigen Ordner; Blogeinträge ihrem Datum entsprechend (z.B. in „2010/11/05“). Der Slug aller Textdateien (es könnte ja durchaus mehr als 1 Eintrag/Tag sein ;)) des jeweiligen Ordners wird mit dem aufgerufenen verglichen usw. usf. Unterstützung für HTML-Dateien baue ich später ein.

    Für den Ansatz eines rudimentären Markdown-Ersatzes greife ich momentan auf die wpautop-Funktion aus WordPress – entsprechend verkürzt/modifiziert – zurück. Über die etwaige „Syntax“ muss ich mir noch Gedanken machen.

    Und an einen eventuellen Export der drupalschen Daten mag ich im Moment erst recht nicht denken.

  7. ben_

    Viel, viel zu lange hab ich hierzu meine Stimme nicht erhoben. Aber solange das Formularfeld noch hier unter dem Artikel steht, ist es ja nicht zuspät. Darum auch mal ein paar Anmerkungen von mir, nichtzuletzt auch mit ein wenig Abstand und Erfahrung.

    Konstantins Blogracer hat gegenüber Heimweh ein paar Vorteile, die ich gerade vor dem Hintergrund meiner Blogpraxis der letzten Monate für wichtiger halte, als zuvor: Das Rendering aller Artikel durch ein PHP-Skript, bringt doch ein paar Bequemlichkeiten mit sich, von denen ich mich inzwischen getrennt habe. Vorwärts/Rückwärtsblättern ignoriere ich inzwischen ebenso wie die Pflege der Lexikonseiten und bei den letzten Artikel habe ich es mir sogar gespart, die Schalgworte noch drunter zu schreiben.

    Die Lösung für mich könnte Jaavscript lauten. Z.B.: Schlagworte einfach einfach als Kommaseparierte Liste in ein bestimmtes p-Element schreiben. Javascript geht nach dem Laden der Seite zu dem Element zersägt es und macht Linkse drum.

    Da ich aber gerade erst wieder Zeit gefunden habe, darüber nachzudenken (geschweige denn, etwas zu programmieren), könnte es mit einer Konkretisierung noch etwas dauern. Bis dahin bin ich latürnich höööchst gespannt, was Du inzwischen so gebastelt hast.

  8. fym

    Zwar mehr schleppend, als mir lieb ist, aber es geht voran.

    Bezeichnenderweise haben mich bisher die Texttransformationen (vor allem in Hinblick auf den drupalschen Export) die meiste Zeit gekostet. Nachdem das irgendwie nicht mehr recht wollte, ich mich selbst in eine Sackgasse manövriert hatte, habe ich das jetzt nochmal komplett umgestoßen und neu angefangen: Für den Export nutze ich jetzt ein entsprechend modifiziertes Markdownify um die Texte aus den Nodes in Markdown-Syntax bzw. in meine dezent abgewandelte Syntax für die txt’s zu bekommen. Im eigenen System sorgt ein zurechtgestutztes autop() und meine fymdown() (I know…) für’s passende Markup der txt’s.

    Unterstützung für HTML-Einträge ist soweit schon drin. Kommentare funktionieren (für txt- und html-„Nodes“) auch, allerdings bisher ohne irgendeinen nennenswerten Spamschutz. Da bin ich mir noch nicht sicher, wie ich den realisieren möchte/kann. Begriffsseiten, die zu einem Term alle entsprechenden Nodes aufzeigen, existieren momentan auch schon. Der Grundstein für Archivseiten ist damit ebenso gelegt, weil sie beide die gleiche Funktion nutzen.

    Es geht weiter. Langsamen Schrittes.

    @konnexus: „Aber manchmal willst Du etwas darstellen (z.B. irgend eine krude Anordnung an Bildern), die Du nicht per Markdown oder ähnlichem darstellen kannst. Das ist so ein Ausnahmefall, da finde ich HTML nicht verkehrt.“

    Ganz und gar nicht verkehrt. Aber für solche Fälle passt die HTML-Unterstützung ja wie die Faust aufs Mark(up). Bevor ich in irgendeine txt HTML packen muss, kann ich so schlicht flugs eine HTML schreiben. Konsequenter. Irgendwie, nicht?

  9. […] Drupal wurde heute Nacht in den lokalen Käfig gesperrt und musste seinen Online-Platz für nihil räumen. Die Erstellung desselbigen hat länger – sehr, sehr viel länger- gedauert, als ich das vorher gedacht hätte. […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert