Eine recht einfache Lösung ist die Beschränkung auf Zahlen. Diese sind oft deutlich besser zu erkennen. Zudem hilft es Menschen, ähnliche Zeichen wie die Ziffer 1 und das kleine l zu unterscheiden.

Die Beschränkung lässt sich global mittels Typo-Script-Konstante aktivieren:

plugin.tx_srfreecap.generateNumbers = 1

Nun muss die Erfahrung zeigen, ob diese Variante auch für Bots zu einfach ist. CAPTCHAs sind keine wirkliche Lösung, sondern ein Usability-Problem. Es würde mich nicht überraschen, wenn Bots die Bildchen bald besser erkennen, als dies Menschen können.

Höchste Zeit für andere Ansätze. Mein Blog fährt mit Obstcha ganz gut. Mehr als zwei, drei Spam-Kommentare im Monat sind eher selten. Mit einem Pagerank von 3 ist die Seite aber auch (noch) nicht der Mittelpunkt des Webs.

Das Ziel

Wir möchten eine Liste von Logs im Browser anzeigen. Da Sortierung und Seiteneinteilung von Javascript übernommen werden, möchten wir direkt 1000 Zeilen der Datenbanktabelle in die HTML-Tabelle übertragen. Die Tabelle soll dabei möglichst schnell ausgeliefert werden.

Der Ablaufplan

Nichts zu sehen? Zur PNG-Version.

Hinweis: Die Darstellung ist nicht ganz korrekt, da der Controller die gerenderten Daten des Templates zurückbekommt und diese in Richtung Ausgabe weiterleitet. Vielen Dank an Alex für diesen Hinweis.

Der Controller

Der Controller verliert in diesem Ansatz die Aufgabe, irgendwelche Daten für die Log-Tabelle zu besorgen. Er muss lediglich das entsprechende Template aufrufen und ggf. andere Jobs erledigen, die neben der Tabelle auf der Seite zu sehen sind.

Das Fluid-Template

Das Template gestaltet das Drum-Herum und ruft darin für die Log-Tabelle einen View-Helper auf. Zudem kann man als Inhalt des View-Helper-Tags ein Template vorgeben, in welchem der Helper nur Variablen ersetzen braucht. Hierfür muss man den allgemeinen Teil von dem trennen, der mit jeder Zeile wiederholt werden muss. Ein simpler Ansatz wäre etwa:

	
			

		
ID
Inhalt
		
%1$d
%1$s
		
	

Das obige Variablenformat lässt sich dann direkt mit PHPs Sprintf-Funktion befüllen.

Der View-Helper

Dies ist die einzige Stelle, an der wie die kompletten Log-Daten zwischenspeichern. Dafür aber gleich im fertigen Ausgabeformat, so dass wir sie nicht noch einmal durcharbeiten müssen. Hierfür nehmen wir eine Singleton-Instanz des Iterator-Repositorys, iterieren über die einzelnen Zeilen der Datenbanktabelle und befüllen hiermit jeweils unser Template. Am Ende geben wir den so zusammengebauten Ausgabestring zurück.

Das Iterator-Repository

Das Repository implementiert das PHP-Iterator-Interface. Dies erlaubt es dem View-Helper, das Repository in einer Foreach-Schleife auszulesen. Der Rest ist relativ simpel: Beim Aufruf von rewind() und dem Konstruktor wird ein Query abgesetzt, das Result speichern wir in einem Klassenattribut, um es in anderen Methoden nutzen zu können.

$this->result = $GLOBALS['TYPO3_DB']->SELECTquery(/*...*/);

Hierbei sollte gleich darauf geachtet werden, dass möglichst viel Logik direkt in SQL erledigt wird. So kann man beispielsweise Datumsformate direkt im Query definieren.
Ein Aufruf von next() setzt ein Row-Attribut mittels

$this->row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($this->result);

Zu guter Letzt muss ein current() noch $this->row oder eine angepasste Variante davon zurückgeben.

Fazit

Die vorgegebenen Code-Schnipsel dienen der Verdeutlichung und sind nicht vollständig. Wenn man dem Ansatz jedoch folgt, kann man sehr direkt auf der Datenbank arbeiten, ohne die offizielle Vorgehensweise von Extbase wirklich zu verletzen.

BE-Gestaltung mit CSS-Datei

Um eine CSS-Datei einzubinden übergibt man dem Fluid-BE-Container einen weiteren Parameter:

<f:be.container
 addCssFile="{f:uri.resource(path:'CSS/style.css')}">
 <!-- Content -->
</f:be.container>  

Die obige Notation bindet dann Resources/Public/CSS/style.css aus eurem Extension-Verzeichnis ein.

Javascript

Mit Javascript geht es ebenso einfach:

<f:be.container
 addJsFile="{f:uri.resource(path:'js/scripts.js')}">
 <!-- Content -->
</f:be.container>

Der Code wird automatisch mit anderem JS zusammengefasst und komprimiert.

Model, View und Controller mit Flow 3

Das MVC-Framework Flow 3 soll noch im Oktober diesen Jahres erscheinen. Ich habe daher mal einen kurzen Blick darauf geworfen und bin über einige tolle Sachen gestolpert, die ich sehr überzeugend finde.

Kommandozeile

In Flow 3 erzeugt man Webapplikationen weitgehend über die Kommandozeile. Die nötigen Dateistrukturen und wesentliche Inhalte von Controllern, Models, Repositorys und Templates werden bereits erzeugt und müssen lediglich angepasst werden. So erzeugt man für einen Blogpost beispielsweise ein recht einfaches Grundgerüst, indem man

./flow3 kickstart:actioncontroller
  --generate-actions
  --generate-related
  TYPO3.Blog Post

im Projektverzeichnis ausführt. Dies erzeugt einen neuen Controller „PostController“ (ein Actioncontroller ist den Zugriff durch den Browser; man kann auch Commandcontoller für die Kommandozeile erstellen). Hierbei werden gleich wesentliche Aktionen wie Hinzufügen und ändern erzeugt (–generate-actions). Die Option –generate-related erzeugt automatisch alles, was noch fehlt: Dies ist hier ggf. das Paket TYPO3.Blog (vorletzter Paramter) und das Model Post, welches passend zum Controller existieren muss. Der letzte Parameter benennt den Controller (ohne das Suffix Controller) und impliziert eine Verbindung zu einem entsprechenden Model.

All das nimmt einem sehr viel Dateiverwaltung und Code-Erzeugung ab. Einen weiteren schönen Einblick in die Kommandozeilenfähigkeiten bekommt man durch das folgende Video:

[vimeo clip_id=“28987131″]

Persistenz an Bord

Eine weitere schöne Sache ist die Verwendung von Doctrine 2: Statt sich hier etwas neues zu überlegen, setzt man auf diese bewährte Lösung, um Objekte ohne viel Aufwand auf Datenbanken zu mappen. Hierfür ist etwas mehr Aufwand im Model nötig. Alle Attribute müssen mittels PHP-Doc typisiert werden:

/**
 * The name
 * @var string
 */
protected $name;

Anschließend kann man diese Models aber mittels eines einfachen Kommandozeilenaufrufs in der Datenbank erzeugen

./flow3 doctrine:migrate

oder später nach Änderungen aktualisieren:

./flow3 doctrine:update

Doctrine ist mittlerweile sehr gut erprobt und bietet unzählige Möglichkeiten.

Wirkt überzeugend – aber was ist mit der Performance?

Was ich bisher gesehen habe, finde ich absolut intuitiv und auch einfacher, als ich es von anderen Frameworks kenne.

Das einzige, wovor ich auf lange Sicht doch ein wenig Angst habe, ist, dass die Entwickler die Performance ähnlich wie bei bisherigen Typo-3-Entwicklungen zu weit hinten anstellen. Schon hier auf dem eigenen Rechner dauerte es manchmal doch erschreckend lange, bis eine Seite vollständig erzeugt wurde. Allerdings war dies meist nur beim ersten Aufruf zu beobachten. Ich denke daher, dass Caching hier über die Geschwindigkeitsprobleme hinweg helfen soll.

Wer selber sehen möchte, was Flow 3 kann, dem sei das Quick-Start-Tutorial ans Herz gelegt.

Typo 3 5

Das neue Typo 3 wird wohl erst Ende nächsten Jahres erscheinen, dennoch zeigte T3N.de in einem Artikel mit Video ein paar schöne erste Eindrücke (das Interview davor ist… merkwürdig, aber wenigstens kurz):

[youtube clip_id=“ihOVcmo6OOI“]