Kwaku Ananse

Ende Juni, als ich einen neuen Beitrag schreiben wollte, meldete mir die Twoday-Software lakonisch, dass mein Abonnement abgelaufen sei, mein Blog ab sofort im kostenlosen Mode weiterlaufen würde und man sich (ich weiß jetzt nicht mehr unter welchen Voraussetzungen) das Recht vorbehalten würde, die Inhalte zu löschen. Inzwischen stehen hier über 500 Beiträge, von denen ich einen großen Teil nicht verlieren möchte. Ich habe eilig per Kreditkarte für das nächste halbe Jahr überwiesen und der Account funktionierte danach auch wieder tadellos.

Bei der Gelegenheit fiel mir ein, dass ich kein Backup habe. Was ich in der Firma für alle meine Kollegen organisiert habe, das lasse ich privat total schleifen. Meistens lösche ich einen hier veröffentlichten Artikel danach auf meiner Festplatte, er existiert dann nur noch im Netz. Ich habe mir in der letzten Woche drei Tage Zeit genommen, um alle Artikel "heim" zu holen, jeden einzeln, denn das von Twoday angebotene Gesamtbackup ist da nicht wirklich hilfreich. In derselben Situation war ich schon mal, als ich vor zweieinhalb Jahren mein angestammtes Diskussionsforum verlassen habe und über 200 Artikel per Hand kopieren musste.

Ein eigenes Textarchiv muss her! Eine klassische Textverarbeitung zu verwenden, hat Nachteile, wenn man die Texte ins Netz stellen will, wenn dort externe Objekte (Videos) eingebunden werden sollen, die Einbindung von Bildern in der Textverarbeitung und in Html unterschiedliche gelöst sind und wenn man auf Hyperlinks nicht verzichten will. Außerdem ist es lästig, einen Text in Html-Syntax zu verfassen, weil der Html-Quelltext wesentlich von seiner Darstellung im Browser abweicht. Die naheliegende Lösung ist es ein Wiki zu verwenden. Die meisten Wikis sind Browserbasierte Systeme, die eines Servers bedürfen und bei denen der Editor im Browser realisiert ist. Für meinen Anwendungsfall kam das nicht in Frage. Zunächst habe ich es mit WikidPad probiert, einer Windows-Anwendung, die einen Editor zur Eingabe von Texten in einer Wiki-Syntax gestattet und über ein Browserplugin verfügt. Die Texte können in Einzeldateien gespeichert werden, die zusätzlich verwendeten Daten (z.B. Bilder) in einem weiteren Verzeichnis. Um eine Übersicht über die Verlinkungen zu behalten, wird zusätzlich eine kleine Datenbank aktuell gehalten. Zwei Nachteile: Das Browser-Plugin ist lausig, an der Wiki-Syntax kann man nichts ändern.

In einem zweiten Versuch habe ich es mit UltraEdit32 probiert, einem Editor mit einem ziemlich großen Funktionsumfang. Unter anderem bietet er die Möglichkeit, eigene in Javascript geschriebene Programme aufzurufen und über die Texte laufen zu lassen. Ich habe mir also meine Bedürfnisse an eine Wiki-Syntax definiert und die entsprechenden Javascript-Routinen geschrieben. Da ich bis dahin kein Javascript kannte, dauert das Schreiben des knapp 1000 Zeilen langen Konverters einen ganzen Tag. Eine einzelne Routine darin sieht etwa so aus:

function replaceBold()
{
  UltraEdit.activeDocument.top();
  do
  {
    UltraEdit.activeDocument.findReplace.find("^.*[*][*].*[*][*].*$");
    if (UltraEdit.activeDocument.isFound() == true)
    {
      UltraEdit.activeDocument.findReplace.replace("[*][*]","<b>;");
      UltraEdit.activeDocument.findReplace.replace("[*][*]","</b>");
    }
  } while(UltraEdit.activeDocument.isFound() == true) 
}

"replaceBold()" läuft einmal durch den Text und schaltet in allen Textabschnitten, die mit 2 Sternchen beginnen und mit 2 Sternchen enden, den Fettdruck ein. Letztendlich befriedigt mich diese Lösung immer noch nicht:

• Für längere Texte wird die Laufzeit unerträglich lang. Bei einem Text, der 500 Links enthält (das Inhaltsverzeichnis) dauert das Formatieren mehrere Minuten, ich habe das Script mehrfach gestartet und wieder abgebrochen, weil ich dachte, das Programm sei abgestürzt.
• Bestimmte Formatierung sind unmöglich, weil ich die Formulierung der entsprechenden regulären Ausdrücke zum Suchen und Ersetzen nicht hinbekomme, die für den sequentiellen Aufruf der einzelnen Ersetzungen notwendig sind.
• Das Problem des lausigen Browser-Plugins bleibt ungelöst, Videos werden nicht angezeigt, die Cascading Stylesheets falsch interpretiert, es fehlen wichtige Navigationshilfen eines "echten" Browsers.

Ich werde das Problem also anders lösen müssen. Wenn man auch in einem richtigen Texteditor keine vollständige Browseranzeige erhält und in einem richtigen Browser keinen vollständigen Editor und die Wiki-Syntax weder in dem einen noch in dem anderen Tool den eigenen Ansprüchen genügt, dann sollte man die drei Komponenten vielleicht einfach trennen?

• Die Texteingabe erfolgt in einem richtigen Texteditor, der auf dem entsprechenden Rechner installiert ist.
• Die Ergebnisanzeige erfolgt in einem beliebigen Browser, der auf dem Rechner verfügbar ist.
• Zwischen beiden vermittelt ein selbst geschriebenes Programm.

In seiner Grundversion muss es nur zwei Algorithmen beherrschen:

1. Scanne das Verzeichnis periodisch auf Dateien vom Typ *.wiki und schaue nach, ob es für diese Dateien Pendants vom Typ *.html gibt. Existieren sie nicht oder sind älteren Datums, dann erzeuge sie.
2. Wenn du sie erzeugst, dann folge der vom Programmierer vorgegebenen Syntax.

Für dieses Programm genügt eine einfache Konsolenapplikation. Man editiert seinen Text, speichert ihn, holt tief Luft (damit das Programm den geänderten Text aus der *.wiki-Datei bemerkt und übersetzt) und wechselt in den Browser. Gefällt einem das Ergebnis nicht, geht man wieder in den Editor und nimmt die Änderungen vor.

Der Textparser muss nicht beliebig ausgefeilt sein, weil er ja in diesem Fall nur meine Anforderungen an die Textformatierung erfüllen muss. Mehr als einen Tag brauche ich für die Implementierung der folgenden Syntaxregeln sicher nicht, weil ich auf Rekursionen gut verzichten kann (also Listen in Tabellen z.B.):

Wiki-Syntax	Ergebnis
//Kursiv//	Kursiv
**Fett**	Fett
__Unterstrichen__	Unterstrichen
--Durchgestrichen--	Durchgestrichen
Hoch^^gestellt^^	Hochgestellt
Tief~~gestellt~~	Tiefgestellt
[[Linkadresse|Linkbezeichnung]]	Linkbezeichnung
[(Bildadresse|Attribute)]
*Nicht nummerierte *Liste	Nicht nummerierte Liste
#Nummerierte #Liste	Nummerierte Liste
<< Inhalt >>	<center> Inhalt </center>
{{ Inhalt }}	<blockquote> Inhalt </blockquote>
(( Inhalt ))	Quelltext, alle Html-Sonderzeichen maskieren
((( Inhalt )))	Objekteinbindung, unverändert lassen
|| Eins || Zwei || || Drei || Vier ||	Eins Zwei Drei Vier
\	Maskierung der Sonderbedeutung eines Zeichens
Leerzeile (oder zwei?)	Neuer Absatz

Wenn dieses Programm gut funktioniert, kann es um weitere Funktionen ergänzt werden:

• Automatische Erstellung eines Inhaltsverzeichnisses
• Automatische Erstellung eines Schlagwortverzeichnisses oder von Clouds.

Das Programm zur Textkonvertierung kann so angelegt werden, dass es als Prototyp für die Konvertierung in andere Zielsprachen dienen kann (OO, PDF).

Kategorie: Alltag