Wenn man selbst Applikationen programmiert die auf Javascript basieren und später noch diverse Erweiterungen ermöglichen sollen, dann macht es durchaus Sinn eigene Callbacks anzubieten. Sei es in einer jQuery Extension oder einer eigenen Applikation.

Die Anforderung

Zur Erfüllung meiner aktuellen Anforderung habe ich eine Javascript Klasse erstellt die mit dem Operator new erstellt werden kann:

var myObject = new FunkyObject();

Perfekt für die erste Anforderung, aber sobald weitere Entwickler involviert werden oder man Teile der Applikation sogar als OpenSource Software veröffentlicht, wäre es ja schön wenn nicht jeder im eigenen Code rum macht sondern ordentlich in seinem Script bleibt:

var myObject = new FunkyObject({
  onLoad: function() {
    //do crazy custom things
  }
});

Sieht ordentlich aus und ist ohne Kommentare selbsterklärend: Beim laden werden verrückte Sachen getan. Aber was tut das FunkyObject um die Callbacks aufzurufen?

Eine Javascript Klasse

Genau genommen ist eine Javascript Klasse nichts weiter als eine Funktion die sich selbst zurück gibt und über den new Operator erstellt wird. Meine Grundlage sieht so aus:

var FunkyObject = function(args) {
  var defaults = {};
  this.args = $.extend(defaults, args);
  this.goCrazy();
  return this;
};

Dieser Code setzt jQuery voraus, das die Funktion $.extend mitbringt. Damit wird das übergebene args Objekt durch die in defaults angegebenen Werte aufgefüllt, sofern sie nicht vorhanden sind. Man kann also für das onClick Event ein Standardverhalten hinterlegen:

var FunkyObject = function(args) {
  var defaults = {
  onLoad: function() {
    //default behavior
  };
  this.args = $.extend(defaults, args);
  this.goCrazy();
  return this;
};

Die Funktion goCrazy() wird ausgeführt sobald die Klasse initialisiert wird. Um dem nächsten Entwickler die Möglichkeit zu geben auch diese Funktion zu überschreiben, werden alle Grundlagen in der prototype Eigenschaft der Klasse definiert:

var FunkyObject = function(args) { /* ... */ };
FunkyObject.prototype.goCrazy = function() {
  // do the init stuff
};

Mit diesem Konstrukt könnte ein Entwickler im eigenen Script jene Klasse überschreiben ohne in den eigentlichen Quelltext eingreifen zu müssen.

myObject.goCrazy = function() {
  // custom constructor
}

Das als kleine Anmerkung am Rande, das erklärte Ziel ist der komfortable Aufruf des onLoad Events. Natürlich könnte man über this.args.onClick() einfach die entsprechende Funktion aufrufen, aber sieht das schön aus? Ist das variabel?

Die Antwort lautet nein.

Schön und variabel

Viel cooler ist eine total schöne und variable trigger() Funktion zu schreiben, die in den Parametern nach einem Callback sucht und diesen ggf. ausführt.

FunkyObject.prototype.trigger = function(action) {
  var callback = 'on'+this.ucfirst(action);
  if(typeof this.args[callback] == 'function') {
    this.args[callback]();
  };
}

In der goCrazy Funktion sieht der Aufruf dann so aus:

var FunkyObject = function(args) { /* ... */ };
FunkyObject.prototype.goCrazy = function() {
  this.trigger('load');
};

Die trigger Funktion baut sich den Eventnamen aus einem on und dem Parameter action zusammen und prüft anschließend ob eine Funktion mit diesem Namen vorhanden ist. Ist dies der Fall wird sie ausgeführt.

Leider gibt es keine Javascript Funktion mit dem Namen ucfirst, aber über die Prototype Eigenschaft kann man das String Objekt entsprechend aufrüsten:

String.prototype.ucfirst = function() {
  return this.substr(0,1).toUpperCase() + this.substr(1,this.length);
};

Mit diesen zwei Funktionen baut man sich sehr schnell eine Grundlage um variable Scripte zu schreiben die komplett erweitert werden können.

Parameter für den Callback

Oft muss der Callback über einen gewissen Zustand informiert werden. Für das benutzte Beispiel könnte es die Information sein ob das Laden erfolgreich war. Bei der Definition des Callbacks muss ein Parameter akzeptiert werden:

var myObject = new FunkyObject({
  onClick: function(success) {
    alert(success ? 'hat geklappt!' : 'fehler');
  }
});

Die goCrazy Funktion muss den Status an die trigger Funktion weitergeben:

FunkyObject.prototype.goCrazy = function() {
  success = true;
  this.trigger('load', success);
};

Wir gehen mal von einem grundlegenden Erfolg aus. Das wird es auch sofern die trigger Funktion beigebracht bekommt was sie mit zusätzlichen Parametern anfangen soll:

FunkyObject.prototype.trigger = function(action) {
  var callback = 'on'+this.ucfirst(action);
  if(typeof this.args[callback] == 'function') {
    this.args[callback](arguments.shift());
  };
}

Viele Änderungen sind es nicht. In der vordefinierten Variable arguments sind sämtliche Parameter vom Aufruf der Funktion gespeichert. Die Array Funktion shift entfernt das erste Element aus dem Array und gibt den Rest zurück. So wird nicht der Callbackname sinnloser Weise an den Callback gegeben sondern alle andere Parameter. So kann man auch mehr als ein Wert an den Callback schicken:

FunkyObject.prototype.goCrazy = function() {
  success = true;
  this.trigger('load', success, 'ready', {hello: 'world'});
};

Fazit

Ich mag Callbacks. Wenn man ein gutes Grundgerüst hat kann man auf alle Events individuell reagieren. Sollte es ein Callback nicht geben den man wirklich dringend und sofort benötigt kann man mit dem Überschreiben der prototype Funktion kurzfristig neue Callbacks hinzufügen und später in die Core Anwendung übernehmen.

Wichtig ist aber darauf zu achten keine unendlichen Scripte in den Callbacks unterzubringen. Spätestens nach 20 Zeilen sollte man sich überlegen den Code in einzelne Häppchen aufzuteilen.

Und in eigener Sache noch die Warnung vor gedankenlosem Copy and Paste: Durch Unterschrift auf dem NDA musste ich alle Funktionen umbenennen. Also nachdenken und gute Funktionsnamen benutzen.

jQuery bietet ja ein tolles Ajaxkonstrukt an mit dem es kein Problem ist Daten vom Server zu holen. Aber auf die Dauer wird es doch etwas nervig immer wieder zu tippen.

Und weil "objektorientiertes Javascript" und selber entwickeln so viel Spaß macht, habe ich mir eine alternative Lösung einfallen lassen: Im Projekt werden an geeigneter Stelle Elemente erzeugt, die alle benötigten Informationen enthalten.

Diese werden in einem Updater registriert, welcher sich um die regelmäßige Abfrage kümmert. Das war die Theorie und jetzt kommt die Praxis.

Das Element

Ein Element besteht aus einer URL auf dem Server, dem Typ der zurückerwartenden Daten und einer Funktion die aufgerufen wird, wenn die Aktion erfolg hatte. Im Quelltext sieht das so aus:

var Paul = new element('count/paul', 'json', function(j) {
  alert("Paul hat "+j.count+" Einträge.");
});

Diese Elemente können überall im Projekt erzeugt werden. Alternativen zu json sind alle Formen die jQuerys Ajaxfunktion erkennt: Html, Text und Jsonp.

Der Updater

Ganz am Anfang (oder am Ende, je nach Geschmack) wird der Updater initalisiert:

var Updater = new updater();

Der Updater akzeptiert zwei Einstellungen:

Updater.intervall = 1000; // Zeit bis zur nächsten Abfrage
Updater.baseurl = "http://kleiner.test.com/"; // String der vor jede URL geschrieben wird

Und hat eine handvoll Funktionen für den dynamischen Umgang mit dem Objekt:

Updater.start(); // Startet den Vorgang sofern Elemente vorhanden sind
Updater.stop(); // Stoppt die Aktualisierungen
Updater.isRunning(); // Prüft ob sich der Updater in Aktion befindet
Updater.log(); // Schreibt alle gespeicherten Elementen in die Konsole
Updater.register(Element); // Fügt ein neues Element hinzu
Updater.remove(Element); // Entfernt ein Element

Die Verwendung

Dem Updater werden beliebig viele Elemente, auch zur Laufzeit, übergeben:

Updater.register(Paul);
Updater.start();

Das wars! Die Funktion im übergebenen Element wird jetzt, im erfolgsfall, alle 1000 Millisekunden aufgerufen.

Die technische Seite vom Element

So sieht das Element aus:

function element(url, dataType, successFunction) {

  //einstellungen
  this.url = url;
  this.data = {};
  this.type = 'get'
  this.dataType = dataType || 'html';

  //callback um die daten zu bekommen
  this.getData = function() {
    return this.data;
  }

  //callback um an die URL zu kommen
  //erster parameter ist die im Updater gespeicherte baseurl
  this.getUrl = function(BASEURL) {
    return this.url;
  }

  //callback wenn eine antwort vorliegt
  //erster Parameter ist die Antwort vom Server, zweiter der Updater an sich
  this.success = successFunction || function(html, Updater) {
    console.log('Anfrage #'+Updater.counter);
    console.log(html);
  }

  //callback wenn ein fehler aufgetreten ist
  //erster parameter ist der Updater an sich um dieses Element daraus zu entfernen
  this.error = function(Updater) {
    //bei einem fehler entfernt sich das objekt selbstständig aus dem updater
    Updater.remove(this);
  }

}

Zwei Funktionen sind wichtig: getData() wird aufgerufen, bevor die Anfrage an den Server gesendet wird. Der Rückgabewert der Funktion wird an den Server geschickt.

Damit ist es also möglich, auf Veränderungen im Frontend zu reagieren. Zum Beispiel:

Paul.getData = function() {
  return {relation: $('body').attr('rel'), project: $('#project_selector').val()};
}

Schön, oder? Natürlich kann man sich noch viel einfallen lassen. Etwa mit der URL, welche mit Hilfe der Funktion getUrl() aus dem Element geholt wird. Es soll ja Fälle geben (CakePHP), bei denen es leichter ist Daten per URL zu übergeben:

Paul.getUrl = function(BASEURL) {
  return BASEURL+this.url+'/'+$('#team .paul').attr('rel');
}

Die Funktionen success(return, Updater) und error(Updater) erklären sich von selbst und haben als Parameter immer das umfassende Element dabei. Deshalb kann sich das Objekt in einem Fehlerfall auch selbstständig entfernen. Es könnte auch das Intervall verändern, ein neues Objekt hinuzfügen, oder was auch immer!

Die technische Seite vom Updater

Als erstes der gesamte Block Quelltext:

function updater() {

  //einstellungen
  this.intervall = 1000;
  this.elements = new Array();
  this.active_element = 0;
  this.baseurl = BASEURL;

  this.running = false;
  this.counter = 0;
  this.timeout = '';

  //alle elemente anzeigen
  this.log = function() {
    console.log(this.elements);
  }

  //neues element hinzufügen
  this.register = function(element) {
    this.elements.push(element);
  };

  //ein element entfernen
  this.remove = function(element) {
    for(i in this.elements) {
      if(this.elements[i] == element) {
        //delete this.elements[i];
        this.elements.splice(i, 1);
        return true;
      }
    }
    return false;
  }

  //elemente durchgehen
  this.process = function(active_element) {
    this.active_element = active_element || 0;

    if(this.elements[this.active_element]) {
      _this = this;
      _elem = this.elements[this.active_element];

      //ajaxaufruf
      $.ajax({
        //einstellungen
        url: _elem.getUrl(_this.baseurl),
        data: _elem.getData(),
        type: _elem.type,
        dataType: _elem.dataType,

        //hat funktioniert!
        success: function(result) {
          _elem.success(result, _this);
        },

        //ein fehler
        error: function(error) {
          //das object soll entscheiden wie es weitergeht
          _elem.error(_this);
        },

        //wie auch immer soll das nächste element aufgerufen werden
        complete: function() {
          _this.next();
        }
      });     

    }
    else {
      this.active_element = 0;
      this.next();
    }
  };

  //ruft process erneut auf, verzögert um intervall mit dem activen element
  this.next = function() {
    if(this.isRunning()) {
      //nur so zum spaß
      this.counter++;

      //zeit die bis zum nächsten aufruf vergehen soll
      var _intervall = 0;

      //nächstes element suchen
      this.active_element++;

      //schon am ende angelangt?
      if(this.active_element >= this.elements.length) {
        this.active_element = 0;

        //längerer intervall bis es wieder los geht
        _intervall = this.intervall;
      }

      //erneut aufrufen
      _this = this;
      _this.timeout = window.setTimeout(function() {
        _this.process(_this.active_element);
      }, _intervall);
      return true;
    }
    else {
      return false;
    }
  }

  //startet den vorgang
  this.start = function() {
    this.active_element = -1;
    this.running = true;
    this.counter = 0;
    this.next();
  }

  //stoppt das updaten
  this.stop = function() {
    this.running = false;
    window.clearTimeout(this.timeout);
    return this.counter;
  }

  //prüfen ob der Updater läuft
  this.isRunning = function() {
    return this.running;
  }
}

Nett, oder? Was ist passiert? Die Einstellungen sollten klar sein. In der Variable timeout wird der aktuelle Timeout gespeichert. Damit kann man beim Abbrechen alle Verbindungen trennen, anstatt noch eine ausführen zu müssen.

Log(), register() und remove() sind an sich uninteressant. Außer eine Erwähnung, dass der Operator delete ein Element zwar entfernt, aber danach nicht das Array neu durchnummeriert. Da liegen dann lauter "undefinied" rum. Deshalb habe ich splice() benutzt. Funktioniert super.

Spannend wird es in der Funktion process(). Diese wird für jedes Element aufgerufen. Als Parameter erwartet sie den Key vom aktiven Element. Wenn ein Element vorhanden ist, wird die Ajaxabfrage ausgeführt.

Innerhalb der Funktion Ajax() bekommt das this eine neue Bedeutung. Deshalb musste ich es in _this zwischenspeichern.

Die Funktion ruft also, je nach umstand, success() oder error() auf und übergibt die Kontrolle an das Element. In jedemfall wird aber _this.next() durch die Funktion Ajax.complete() aufgerufen. Diese wird, unabhängig vom Status, nach jeder Ajaxanfrage ausgeführt.

In der Funktion next() wird das nächste Objekt gesucht. Sofern der Updater läuft isRunning() wird der Counter erhöht und das Intervall auf Null gesetzt. Das passiert, weil alle registrierten Elemente sofort nacheinander aufgerufen werden sollen und erst anschließend die in this.intervall angegebene Zeit gewartet wird.

Wenn alle Elemente durchgearbeitet wurden, wird der Index auf Null und der Intervall auf die eingestellte Zeit gesetzt.

Anschließend gibt es ein klassisches window.setTimeout() um das ganze Spielchen wieder von vorne anzufangen.

Start(), stop() und isRunning() erklären sich wieder von selbst, und damit ist die Vorstellung beendet!

Fazit

Der große nächste Erweiterungsschritt ist in dem Updater alle Anfragen zu sammeln und in einem Packet an den Server zu schicken. Die Antwort kann dann direkt vom Updater auseinander gefriemelt und an die verschiedenen Elemente verteilt werden.

Dazu muss der Server allerdings noch vorbereitet werden, und bisher sind es noch nicht viele Benutzer. Aber ich denke es ist eine solide Grundlage die gut erweitert werden kann.

Das war auch die Intention dieses Postings. Hast du einen Vorschlag? Kritik? Hinweis? Freue mich über Kommentare und Inspiration. Danke für die Aufmerksamkeit.

Tja, einfach ist das natürlich nicht und jedes Programm erstellt andere CSV Dateien. Ich habe eine Funktion geschrieben die versucht automatisch zu erkennen wie eine CSV Datei aufgebaut ist. Hier ist eine Demo und im folgenden Artikel kommt die Funktionsweise.Die Funktion erwartet einen String, z.B.

"spalte1", "spalte2", "spalte3"

Array(  [delimiter] => ;   [enclosure] => ")

Hier kommt die komplette Funktion und anschließend ein paar erklärende Worte.

function csv_autodetect($string) {
  $str = trim($string);
  $char = '';
  $e = '';
  $d = array();
  $open = false;
  $strip = false;
  for($i = 0; $i < strlen($str); $i++) {
    $char = $str[$i];
    if(preg_match('=[\W]=', $char) && ord($char) != 32) {      
      if($i == 0)
        $e = $char;
      
      if($char == '\\')
        $strip = true;
      else
        $strip = false;
      
      if($char == $e && !$strip) {
        $open = $open ? false : true;
      }
      else {
        if(!$open && !$strip)
          $d[$char]++;
      }
    }
  }
  
  asort($d);
  $dd = array_keys($d, array_pop($d));
  $return['delimiter'] = $dd[0];
  $return['enclosure'] = $e;
  return $return;  
}

Nachdem einige Variablen vorbelegt wurden, erfolgt die zeichenweise Untersuchung des Strings. Wenn es sich um ein Sonderzeichen handelt, dann beginnt die Untersuchung.

if($i == 0)
  $e = $char;

if($char == '\\')
  $strip = true;
else
  $strip = false;

if($char == $e && !$strip)
$open = $open ? false : true;

if(!$open && !$strip)
  $d[$char]++;

Der Grund dafür ist das eventuelle Auftreten von Sonderzeichen in einer Spaltenbezeichnung ohne Enclosure (z.B. spalte1, spalte2&3, spalte4). Am Ende wird das Zeichen als Delimeter erwartet welches am häufigsten gefunden wurde. Das gibt zwar ein Problem bei einem String wie c&a, p&c, m&m - aber dann muss man seine Felder halt mit einem Zeichen umschließen.

Ende! Wer jetzt in seinem Kopf die Idee spinnt daraus ein Tool zu bauen welches CSV Dateien in eine Datenbank importiert, dem sei geraten noch ein paar Tage zu warten oder mir eine Mail zu schicken. Hab da was tolles in der mache was demnächst veröffentlicht wird .

Wer Ideen, Probleme und Verbesserungsvorschläge hat kann diese gerne in den Kommentaren los werden.

In diesem Beitrag will ich erklären wie es dank Hooks und dem TCEMain Objekt möglich wird, in die TYPO3 internen Speicherfunktionen zu kommen. Das braucht man für seine eigenen Extensions oder wenn man vor dem Speichern die Daten manipulieren möchte.
Vorne weg sei gesagt, dass Robert Lemke schon ein ausführliches, englisches Tutorial geschrieben hat welches die Sache sehr gut und ansehnlich erklärt. Wer nicht so viel Zeit hat oder keine Lust auf Englisch, dem wünsche ich viel Spaß!

Eine eigene Klasse

Wir brauchen eine neue Datei in der wir unsere eigene Funktionalität festhalten. Diese braucht eine einzige Funktion, welche schon im Titel erwähnt ist: processDatamap_postProcessFieldArray.

class tx_EXTNAME_tcemainprocdm {
	function processDatamap_postProcessFieldArray($status, $table, $id, &$fieldArray) {
		// ACTION!
	}
}

EXTNAME ist hier wie im folgenden stets entsprechend anzupassen.
Wir erstellen also eine Funktion die eine ganze Reihe Parameter bekommt. Bei Robert Lemke hat sie auch noch ein &$this als letzten Parameter, da hat er bei mir aber rumgemeckert.
$status beinhaltet die gewählte Aktion (z.B. "update" oder "insert").
In $table steht die Tabelle um die es geht.
Und $id kennzeichnet den betreffenden Datensatz. Reicht für meine Zwecke.

Den Hook registrieren

Dafür wechseln wir in die Datei ext_localconf.php und fügen eine Zeile hinzu, welche unsere Klasse referenziert:

$GLOBALS["TYPO3_CONF_VARS"]["SC_OPTIONS"]["t3lib/class.t3lib_tcemain.php"]["processDatamapClass"][] = "EXT:EXTNAME/class.tx_EXTNAME_tcemainprocdm.php:tx_EXTNAME_tcemainprocdm";

Der Datei t3lib_tcemain.php wird also unser Hook zugeteilt. Es ist darauf zu achten das dem Array ein neues Element hinzugefügt wird und durch das Konstrukt Dateipfad:Klassenname die Einbindung mittels require entfällt. Praktisch!

Das wars!

Nichts leichter als das. Wenn man mit Echo in der eigenen Funktion etwas ausgibt erscheint es nach dem Speichern eines Datensatzes über der Leiste mit den Speichernknöpfen, also keine Hemmungen und viel Spaß mit dem Logikmonster TYPO3!

Hier kommt eine kleine Anleitung wie man den Inhalt auf Buchstaben und Leerzeichen überprüft und eine Abhängigkeit von mehreren "Kontrollkästchen" - auch Checkboxen genannt - erzeugt.

Grundlegend

In den JavaScripten gibt es zwei Objekte die für mich interessant sind.

this

Bezieht sich auf das gesamte Dokument und beinhaltet u.a. alle Formularfelder.

event

Beinhaltet das aktuelle, angeklickte Element und erlaubt den Status zu setzen.

1. Inhalt auf "echte Zeichen" überprüfen

Wir haben ein Textfeld zur Eingabe von Formulardaten. Hinter einem Doppelklick verstecken sich die Feldeigenschaften. Hinter dem Button "Validierung" gibt es die Möglichkeit ein "Benutzerdefiniertes Validierungsscript aus(zu)führen". Perfekt. Nehmen wir, und so siehts aus:

if(event.value.search(/[^a-z ]/gi) == -1) {
    event.rc = true;
}
else {
  event.rc = false;
  app.alert("Bitte geben Sie nur Buchstaben ein.");
}

Über die Eigenschaft event.value bekommen wir den Inhalt des Formularfeldes nach der Eingabe (das regelt das PDF für uns). Mit der Funktion search() wende ich einen regulären Ausdruck auf den Inhalt an. [a-z ] trifft auf alle Buchstaben und das Leerzeichen zu. Mit "i" wird die Groß- und Kleinschreibung ignoriert und "g" durchsucht den String bis zum Ende. Mit dem Dach (^) negieren wir die Auswahl - wird also nichts anderes außer Buchstaben oder das Leerzeichen gefunden, ist alles in Ordnung und der Return Code (rc) wird positiv; der Inhalt hat die Validierung bestanden (bei AddedBytes gibts ein gutes Cheat Sheet zu regulären Ausdrücken).
Ist dies nicht der Fall, negieren wir den Return Code, was ein verlassen des Feldes verhindert, bzw. den Standardwert setzt. Über app.alert() wird der Benutzer noch darauf hingewiesen (ohne app funktioniert es nicht).

2. Abhängigkeiten von Checkboxen

Das Problem: Wenn eine Checkbox gewählt ist, dann dürfen eine ganze Reihe anderer Felder nicht ausgewählt werden. Alltäglich...
Bei den Checkboxen gibt es keine Validierung, deshalb fügen wir eine neue Aktion hinzu: Bei "Maustaste loslassen" wird ein JavaScript ausgeführt, undzwar folgendes.

if(this.getField("FELDNAME_1").value == "VALUE_1") {
  this.resetForm(["FELDNAME_2"]);
}

Bedeutet: über this.getField().value bekommen wir den Inhalt der ersten Checkbox (mit Namen FELDNAME_1), welche die Abhängigkeit auslösen soll. Ist sie nicht ausgewählt, besitzt sie auch keinen Inhalt (VALUE_1).
Falls doch, wird mit this.resetForm() der Standard wieder hergestellt. Als Parameter wird der Feldname als Array übergeben. Es könnten also auch mehrere Felder zurück gesetzt werden mit resetForm(["FELD_1", "FELD_2"]) - man achte auf die korrekte Klammerung.

Fazit

Alles in allem eine ehr anstrengende Geschichte, aber ich denke sie funktioniert. Die Informationen im Netz sind spärlich, geholfen hat mir aber das endlose PDF JavaScript in Acrobar API. Die offizielle Acrobat Hilfe bietet einen ersten Einstieg - und setzt erfreulicher Weise auf jQuery

Nur leider sieht es nicht besonders schön aus. Mit einfachen Mitteln lässt sich das aber sehr schnell ändern, und schon surft man voller Freude durch die eigene Ordnerstruktur.
So könnte man es machen:

Standardschriftart im Browser ändern. Mit zweieinhalb Klicks ist Verdana oder Arial eingestellt was einen wesentlich angenehmeren Eindruck auf ungestylten Seiten hinterlässt. Im Firefox gehts über
Einstellungen > Inhalte > Schriftarten und Farben.

Die htaccess im Heimatverzeichnis anpassen. Der Apache Webserver bietet umfangreiche Möglichkeiten um das Listning anzupassen. Besonders interessant wird es mit eigenen Header- und Footer-Dateien. So sieht es bei mir aus:

# Serversignatur ausschalten. Ich weiß ja schon was ich für einen Server installiert habe.
ServerSignature Off

# Anzeigen vom Verzeichnisinhalt, sofern keine index.html/index.php vorhanden ist.
Options +Indexes

# Jetzt wirds verschönert!
IndexOptions HTMLTable FancyIndexing

# Einen eigenen Header einbinden. In dem ist Platz für CSS und JavaScript
HeaderName /server/header.html

# Wir brauchen überhaupt keinen Footer.
IndexIgnore footer.html

# Verhindern das die Tabelle in eigene Bodytags verschachtelt wird
IndexOptions SuppressHTMLPreamble

# Manchmal will man auch die kleinen Icons anklicken.
IndexOptions IconsAreLinks

# Zeigt die HTML Titel in den Beschreibungen an.
# Kommt aber selten zum Einsatz, da meistens eine index Datei vorhanden ist
IndexOptions ScanHTMLTitles

# Die Spalte Beschreibung soll lang genug sein
IndexOptions DescriptionWidth=*

# Und eine Standardsortierung. Die zickt aber manchmal rum...
IndexOrderDefault Ascending Name

Das wars! Und schon sieht das ganze wesentlich angenehmer aus.

Tiefschürfende Informationen über alle Möglichen htaccess Einstellungen gibt es bei trash.net (de) oder direkt von den Machern (en).

Wer keine Lust hat selber Dateien anzulegen, lädt sich dieses Archiv runter und entpackt es in das Heimatverzeichnis des Webservers. In der header.html befindet sich das Styling welches die Ausgabe einfärbt.

Und was fehlt? Mengen an Blindtext! Da wir gerade ein neues Projekt auf diese Art und Weise begonnen haben, standen wir vor genau diesem Problem. Es folgt ein einfacher Lösungsansatz mit PHP.

Wer jetzt Mengen an Text erwartet hat, den muss ich leider entäuschen. Ich habe eine Mini-PHP Klasse geschrieben: Blindtext.
Diese besitzt genau eine Funktion: get(). Die Funktion kann aufgerufen werden ohne ein neues Objekt der Klasse zu erzeugen und kann mit zwei Parametern gesteuert werden. Die in Klammern gesetzten Werte sind die Standardwerte.

$length (= 100) - Anzahl von Zeichen die der Blindtext enthalten soll
$dot (= true) - Setzt einen Punkt an das Ende des Blindtexts, wenn true

So einfach! Das Besondere an der Klasse ist die dynamische Ausgabe. Es ist ein String (Lorem ipsum...) gespeichert von dem zufällig die ersten Zeichen abgeschnitten werden. Damit erhält man nicht immer den gleichen Blindtext.

So gehts:

<?
  include("blindtext.php");
  echo blindtext::get(200);
?>

Ich spare mir jetzt mal die Ausgabe als Beispiel dazu zu schreiben.

Hier ist der download.

Aber ich habe einige Ansätze gefunden die funktionieren.

TSConfig erweitern

Normalerweise definieren wir den RTE über das TSConfig Feld der Root Seite. Da der Benutzer der Extension dies aber nicht tun soll, erledigen wir das über die ext_localconf.php unserer Extension.

Hier ist es Möglich eine Variable, z.B. $rte_config, dem TSConfig hinzufügen:

t3lib_extMgm::addPageTSConfig($rte_config);

In meinem konkreten Fall habe ich ein weiteres Tag definiert, hivar, welches ich gesondert formatieren möchte. Zur Lösung führte dann endlich folgendes:

RTE.default {
  ignoreMainStyleOverride = 0
  mainStyleOverride = hivar { color:darkred; usw. usf. }
}

Hinter mainStyleOverride kann man natürlich alles mögliche packen, besonders wichtig ist die zweite Zeile. Ansonsten zeigt es keine Wirkung, egal was man tut!

Grafiken über CSS im RTE

Möchte man per CSS Grafiken einbinden, muss man zwei Ebenen nach oben wechseln um im Rootverzeichnis des Projektes zu landen. Von hieraus am besten straight zur eigenen Extension:

background-image:url(../../typo3conf/ext/hivars/ext_icon.gif)

Eigene Tags hinzufügen

Besonders angenehm ist auch die relativ neue Funktion addToList, womit ein komplettes überschreiben der vorhandenen Einstellung vermieden wird:

allowTags:=addToList(hivar)

Ausblick

Demnächst, oder in dringenden Fällen auf Anfrage, gibt es die gesamte RTE Konfiguration. Davor muss ich noch einige Dinge erweitern, vervollständigen und die Wechselwirkungen mit vorhanden Einstellungen untersuchen. Zum Glück haben wir einige Projekte in denen ich testen kann und die verwirrten Redakteure beobachten wenn irgendwas nicht mehr funktioniert.

Hoffentlich bleibt es nicht für immer so warm...

Funktionsweise

Die ausführliche Beschreibung finden Sie hier. Die Regeln habe ich weiter vereinfacht. Mein PlugIn prüft aktuell nur 3 von 5:

1. Zeit
   Ein Kommentator muss mind. 5s benötigen um einen Kommentar zu schreiben. Ansonsten ist er eine Machine.
2. Vertauschte Bezeichnungen
   Im HTML Formular sind Name und Emailfeld von den Bezeichnungen her vertauscht. Ist eine E-Mailadresse im Namenfeld eingetragen, handelt es sich mit ziemlicher Sicherheit um unerwünschte Werbung.
3. Hiddenfield
   Ein verstecktes Formularfeld (<input type="hidden") muss leer bleiben. Spamroboter füllen meistens sinnlos alles aus.

Schon wenn eine der Regeln zutritt wird der Kommentar abgewiesen.
Zum verfolgen der Tätigkeiten wird eine simple Logdatei beschrieben. Dieses Verhalten sollte man bei vielen Spamnachrichten abschalten.

Installation

Nach dem Download in den Ordner wp-content/plugins/ verschieben und im WordPress Backend aktivieren.

Anschließend müssen noch ein paar Dinge im Formular der Kommentareingabe angepasst werden. Je nach Theme unterschiedlich, meistens findet sich dies aber in der Datei wp-content/themes/THEME-NAME/comments.php.

1. Attribut Action vom Form-Tag

   Ich habe keinen anderen Weg gefunden in die Abarbeitung einzugreifen. Deshalb habe ich sie ersetzt. Das Attribut Action muss auf folgende Datei zeigen:

   <?php echo get_option('siteurl'); ?>/wp-content/plugins/id-spamkill/id-comments-without-spam.php

2. Bezeichnungen vertauschen

   Name und ID vom Namen und E-Mailfeld vertauschen. Nicht vergessen auch das for-Attribut vom Label anzupassen. Bei mir sieht es jetzt so aus:

   <p class="first">
   	<label for="email">Name <?php if ($req) echo "(erforderlich)"; ?></label>
   	<input class="styling" type="text" name="email" id="email" value="<?php echo $comment_author; ?>" size="22" tabindex="1" />
   </p>
   
   <p>
   	<label for="author">eMail <?php if ($req) echo "(erforderlich)"; ?></label>
   	<input class="styling" type="text" name="author" id="author" value="<?php echo $comment_author_email; ?>" size="22" tabindex="2" />
   	<span>(wird nicht veröffentlicht)</span>
   </p>

3. Innerhalb der beiden Form-Tags müssen die Hooks abgearbeitet werden. Auch das sollte bei den meisten Themes schon vorhanden sein:

   <?php do_action('comment_form', $post->ID); ?>

Zu guter letzt muss die Datei wp-content/plugins/id-spamkill/id-spamlog.txt für das Script noch beschreibbar gemacht werden (z.B. mit chmod(0777)). Das wars! Einträge werden gefiltert.

Konfiguration

Viel muss beim Plugin nicht konfiguriert werden. Da es so wenige Sachen sind sie noch nicht als "normale" Einstellungen über das Backend erreichbar sondern in der Datei id-spamkill.php zu finden. Ab Zeile 13 geht es los:

protected $logSpam = true;   // Spamlog speichern?
protected $logFile = "id-spamlog.txt";    // Datei in der das Spamlog gespeichert wird
protected $logSep = "\n-----------------------------------------------\n";    // Trennezeichen zwischen dein einzelnen Einträgen der Logdatei.

Download

Das Plugin kann als Archiv herunter geladen werden. Bei der Verwendung wäre eine kurze Nachricht nett.

Fazit

Das Plugin ist in einer sehr frühen Version und bietet noch viel Raum nach oben. Gerade die aufwendige Installation stört mich gewaltig, aber ich habe bisher keinen anderen Weg gefunden um so tiefgreifend das System zu verändern.

Ich habe ein gutes Gefühl und lade alle Besucher herzlich ein, mit mir zu beoachten welcher Spamkommentator es als erstes schafft durch zu kommen.

Bei Fragen, Problemen und Anregungen stehe ich gern zur Verfügung.

Besonders gefreut habe ich mich über den dritten Punkt: "Use -moz-opacity:0.99 on text elements to clean up rendering in Firefox". Gleich getestet und es stimmt: Mit dieser CSS Angabe verhindert man das lästige zucken der Schrift bei JavaScript Effekten!

Insgesamt finde ich es aber falsch jedes Mal alle Schwächen vom IE6 auszubügeln. Den betreffenden Benutzern muss klar gemacht werden, dass sie alte und schlechte Software benutzen. Einen guten Weg geht die Initiative SaveTheDevelopers.org. Mit einem kleinen JavaScript werden die Besucher dezent auf den Umstand aufmerksam gemacht.