Kurz gesagt: ein neues Telefon musste her, und das sollte nach Möglichkeit vor Features nur so strotzen. Nach dem von Nokia - eigentlich meiner ersten Wahl - in naher Zukunft nichts brauchbares zu erwarten war, und deren Smartphones ja allgemein nicht sehr berühmt sind, fiel mein Blick ziemlich rasch auf die Android-Sparte. Dabei traf es sich, wie der Zufall so wollte, zeitlich gerade so, dass bald das zweite "Google-Phone" - das Google Nexus S von Samsung - erscheinen würde.

Mein Versuch, das Handy über Amazon zu bestellen, war zunächst nicht von Erfolg gekrönt, also habe ich es mir in einem kleineren Einzelhandelsbetrieb bestellt (und natürlich den vollen Preis bezahlt - im Gegensatz zu der Strategie sich das Handy von einem Netzbetreiber sponsern zu lassen, und dafür die nächsten drei Jahre den betreffenden Netzbetreiber über exorbitante Grundgebühren zu finanzieren). Dazu noch ein passender Smartphonetarif mit unlimitiertem Datenvolumen und alles war perfekt.

An dem Nexus S von Google gibt es nur kaum irgendetwas auszusetzen. Maximal vielleicht der integrierte Speicher, der sich nicht über SD-Karte erweitern lässt (aber mit 16 GB durchaus nicht zu klein gewählt ist), oder unter Umständen die Kamera, welche "nur" 5 Megapixel hat. Ansonsten ist es sicherlich ein Spitzengerät. Durch die "pure Google" Philosophie des Gerätes lässt sich der Bootloader in wenigen Handgriffen über das Android SDK entsperren, und in weiterer Folge einfach ein alternatives ROM Image aufspielen. Dazu braucht man den Clockwork Mod als Recovery System installiert, und über den kann dann das gewünschte System einfach von der Speicherkarte auf das Gerät geladen werden. Momentan verwende ich den Cyanogen Mod, welcher sicherlich einer der populärsten Alternativ-Android ROMs ist.

Damit hat man auch root-Zugriff auf das nun "leicht" modifizierte System und kann sich Anwendungen installieren, von denen Benutzer anderer Smartphonehersteller vielleicht nur zu träumen wagen. Darunter su, ssh, busybox, einen Webeblocker, das Qt Framework, Firefox und wem das noch nicht reicht, der kann sich ja mit dem Android NDK nach belieben weitere native Anwendungen bauen und installieren. Die von Google mitgelieferten Apps wie Maps, Kalender, Gmail, Youtube und der Reader sind ganz praktisch - besonders die integrierte turn-by-turn Navigation in Maps - und lassen sich auch noch mit weiteren Bausteinen aus dem Google Sortiment aufstocken (z.B. Google+, Google Sky Map, Google Goggles, Street View usw.). Wem das noch immer nicht reicht, dem stehen abertausende Apps im Market zur verfügung - sowohl gratis als auch zum Kauf.

Der vorinstallierte Musikplayer hat mein Herz, bereits durch die Fähigkeit OGG Vorbis Dateien abspielen zu können, erobert und mit einem "richtigen" IMAP E-Mail Programm  wie K9 Mail im Zusammenspiel mit IRC, SMS und dem kompletten Internet ist auch das Bedürfnis nach Kommunikation ausreichend befriedigt.
Ergänzt wird das Übermaß an Features durch die problemlose automatische Synchronisation der wichtigsten Daten mit dem Google Account und die uneingeschränkte Möglichkeit der Internetfreigabe durch Tethering über USB und als WLAN Access Point.

Die Akkulaufzeit ist mit etwa zwei Tagen bei durchschnittlicher Verwendung ganz akzeptabel, und für ein Smartphone nichts erschreckendes.

Es bleibt mit der ganzen Fülle an Möglichkeiten nur abzuwarten, was Android 4 (alias "Ice Cream Sandwich") an Neuerungen bringt. In der zwischenzeit: nicht vergessen regelmäßig ein Backup zu machen! ;-)

PHP beschleunigen

Im Internet findet man zur Geschwindigkeitsoptimierung von PHP Scripten mehrere op-code Caches, die mehr oder weniger das geparste, maschinenlesbare PHP Script zum schnelleren Zugriff zwischenspeichern, damit nicht bei jedem Seitenaufruf neu geparst werden muss. Mein Favourit ist APC, da dieses als Pecl Package verfügbar ist und somit einfach als PHP Modul ohne weitere Abhängigkeiten kompiliert und eingebunden werden kann. Auch soll es in der kommenden PHP Version 6.0 als ein fixer Bestandteil von PHP integriert werden.

Um APC zu installieren setze ich hier für die Anleitung Apache2 und PHP5 aus dem Paketmanager voraus (alle Pakete beziehen sich auf Debian/Ubuntu). Zunächst benötigt man die Quellpakete von PHP und Apache, sowie die standard Build-Tools und PHP PEAR

apt-get install build-essential php5-dev apache2-threaded-dev php-pear

Als nächstes erzeugen wir einen zusätzlichen Link auf das Apache Extension Tool Binary, um einen bekannten Fehler zu umgehen.

ln -s /usr/bin/apxs2 /usr/bin/apxs

Ist das geschehen kann die Installation von APC starten. Mit folgendem Kommando sollte der Prozess einfach durchlaufen.

pecl install apc

Nun muss die Extension noch in die Datei /etc/apache2/php.ini eingetragen werden. Dazu sucht man darin nach folgendem Abschnitt

;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;

Dort muss man folgende Zeile eintragen

extension=apc.so

Außerdem, falls noch nicht vorhanden, wird ein eigener Bereich für die APC Konfiguration am Ende der php.ini angelegt, wo man die spezifischen Einstellungen vornehmen kann. Eine genaue Beschreibung der verschiedenen Parameter gibt es unter http://php.net/manual/de/apc.configuration.php

[APC]
apc.enabled=1
apc.shm_segments=1
apc.optimization=0
apc.shm_size=128
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.enable_cli=0
apc.rfc1867=1

Im Anschluss muss Apache neu gestartet werden

/etc/init.d/apache2 restart

Mit folgendem, kurzem Script kann getestet werden, ob die Erweiterung wie erwartet funktioniert

<?php
$bar = 'BAR';
apc_store('foo', $bar);
var_dump(apc_fetch('foo'));
?>

MySQL Queries cachen

Es bringt die schnellste Scriptsprache nichts, wenn ewig auf die Kommunikation mit der Datenbank gewartet werden muss. Natürlich werden Abfragen schneller ausgeführt, sind etwa die Indizes einer Tabelle bereits im Hauptspeicher vorhanden - immer vorausgesetzt, der Server hat ausreichend RAM. Daraus lässt sich ableiten: je mehr RAM auf einem Datenbank-Server umso besser. Eine Möglichkeit MySQL weiter zu beschleunigen, ohne gleich neue Hardware zu besorgen, ist den Query Cache zu aktivieren. Dadurch werden, je nach Konfiguration, alle oder nur manche SELECT Abfragen zwischengespeichert und bei einem erneuten Aufruf folglich schneller ausgeführt.

Verbindet man sich mit root beim MySQL Server, kann man mit der folgenden Abfrage überprüfen, ob es nicht vielleicht schon aktiviert ist, bzw. sobald es aktiviert ist, erhält man damit einen kurzen Überblick zum momentanen Status.

mysql> SHOW VARIABLES LIKE '%cache&';

Wird als "query_cache_size" der Wert 0 angezeigt, ist dieses noch nicht eingeschaltet. Dies erledigt man, indem man in der /etc/mysql/my.cnf die folgenden Zeilen einträgt bzw. auskommentiert.

query_cache_limit = 16M
query_cache_size  = 128M
query_cache_type  = 1

Dabei gilt das Cache Limit für die größe einer Query, die gecached werden kann, die Cache Size legt die gesamtgröße des Caches fest und der Cache Type "1" aktiviert das Cache standardmäßig für alle Queries. Würde man den Type auf "2" setzen, wäre der Cache nur für Queries aktiv, die "SQL_CACHE" im Statement enthalten. Damit könnte man gezielt nur einzelne Queries cachen.

Nun muss natürlich noch der MySQL Server neu gestartet werden. Mit der vorherigen Abfrage zum Status des Caches müssten wir jetzt beobachten können, wie sich bei Verwendung der Datenbank langsam das Cache füllt. Dabei ist es interessant, das Verhältnis zwischen Cache Hits und Cache Inserts zu betrachten. Dieser Faktor gibt Auskunft darüber, wie effektiv das Cache genutzt wird.

Natürlich können Queries, die gewisse Funktionen wie etwa UUID oder CURRENT_TIMESTAMP verwedenden oder Prepared Statements nicht gecached werden.

Eine sehr gute Einführung in die Thematik und auch ein paar wichtige Dinge, die es bei der Verwendung vom Query Cache zu beachten gibt, findet man unter http://www.docplanet.org/mysql/mysql-query-cache-in-depth/ und http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/

Für alle, die noch immer nicht zufrieden mit der Geschwindigkeit oder dem Funktionsumfang des eingebauten MySQL Query Caches sind, soll memcached ans Herz gelegt sein. Dieser wird zwischen Webserver und Datenbank gehängt, und übernimmt das Cachen der Datenbankabfragen. Für Setups, die auf mehrere Server verteilt sind, kann man Datenbank- und Webserver auch voneinander trennen und memcached auf dem Webserver laufen lassen, oder man richtet für memcached gleich eigene Server mit haufenweise RAM ein. Man hört, es soll ausgesprochen schnell und flexibel sein, damit zu arbeiten, und dadurch vor allem für größere Projekte geeignet sein.

Wer allerdings heutzutage nicht asynchron mit dem Server kommuniziert ist ja fast schon von Gestern. :-) Fast ausnahmslos alle modernen Web-Applikationen nutzen Ajax, weshalb ich es gerne sehen würde, wenn diese Form der Kommunikation mit Extbase besser dokumentiert wäre. Denn nicht nur ist es für einen Einsteiger eine Hürde, sondern auch für Entwickler, die sich mit Typo3 schon länger beschäftigen, ist dies ein unnötiger Stolperstein.

Zunächst muss ein eigener Page Type für Ajax Requests spezifiziert werden, mit dem sämtlicher Output auf das wesentliche, nämlich die Ajax Antwort, reduziert wird und um zu verhindern, dass Typo3 die Ausgabe nachträglich abändert. Dazu muss folgendes in das TS Setup eingetragen werden.

tmp.ajaxConf = PAGE
tmp.ajaxConf {
  typeNum = 1249058000
  config {
    disableAllHeaderCode = 1
    xhtml_cleaning = 0
    admPanel = 0
  }
}

my_plugin_page < tmp.ajaxConf
my_plugin_page {
  typeNum = 1296727024
  10 < tt_content.list.20.myplugin_pi1
}

Der erste Block sorgt dafür, dass keine zusätzliche Ausgabe erzeugt wird und die Ausgabe nicht verändert wird (etwa durch das Admin Panel). Im weiten Block wird die Konfiguration einem TS Objekt zugewiesen und dem Plugin zugeordnet. Hier sollte man als typeNum beispielsweise den aktuellen Timestamp verwenden. Was auch immer man an dieser Stelle tatsächlich verwendet, wird dann bei den Ajax Requests der Wert für den Parameter "type". Den tatsächlichen Pfad zum tt_content Eintrag für das eigene Plugin findet man am einfachsten über den TS Objekt-Browser unter "Template".
Damit sollte man zumindest schon mal die Voraussetzung für Ajax mit Extbase geschaffen haben.

Nun muss man eine entsprechende Aktion in einem Controller schreiben, die etwas zurückliefert, womit JavaScript etwas anfangen kann. In meinem Beispiel wird für einen User eine neue Adresse angelegt und die Seite bekommt vom Server eine Antwort in JSON.

/**
 * add a new adress to a user
 * @param Tx_MyExt_Domain_Model_Address
 */
public function addAdressAction(Tx_MyExt_Domain_Model_Address $addr) {
  if( isset($this->user) ) {
    $this->user->addAddress($addr);
    $addr->setUser($this-user);

    // persist manually to get the new id of the inserted record
    $pM = t3lib_div::makeInstance('Tx_Extbase_Persistence_Manager');
    $pM->persistAll();

    // now we can respond with something useful
    return json_encode(array(
      'status'  => 'OK',
      'newId'   => $addr->getUid(),
      'country' => $addr->getCountry(),
    ));
  }
  return json_encode(array(
    'status'  => 'ERROR',
    'message' => 'You are not allowed to do this',
  ));
}

Jetzt kann der Server schon mal Antworten, fehlt nur noch der Teil auf der Clientseite, mit dem die Action aufgerufen wird und die Antwort entsprechend verarbeitet werden kann.

Ich verwende dazu vorzugsweise jQuery. Die URL, die aufgerufen werden soll, wird generiert, und dann in einem inline <script> Teil an das Javascript zur Verwendung übergeben. Von dort aus kann dann der Ajax Request gestartet und anschließend verarbeitet werden.

<script type="text/javascript">
var addr = <f:uri.action action="addAddress" controller="MyController" arguments="{type: 1296727024}" />

// onsubmit
var form = $('form');
$.post(addr, form.serialize(), function(response) {
    var data = $.parseJSON(response);
    // do something useful with the response
});
</script>

<f:form method="post" action="addAddress" controller="MyController" name="address" object="{address}">
...
</f:form>

Damit sind alle Bausteine, die man braucht um Ajax mit Typo3 und Extbase zu verwenden beschrieben. Mit diesen grundlegenden Bausteinen kann jetzt losgelegt werden eigene coole neue Plugins für Typo3 zu schreiben ;-)

Hat man es dann auch noch mit Kunden zu tun, die in den Gestaltungsprozess eingebunden werden müssen, jedoch nicht die Arbeiterschaft mit ihren E-Mails quälen sollen, bleibt fast nur mehr der Griff zu einem Ticketsystem. Dieses soll natürlich auch noch Problemlos mit der zuvor erwähnten Versionsverwaltung zusammenspielen können.

Ich konnte mich, nach ein wenig Recherche im Internet, schnell für das in Ruby on Rails geschriebene Redmine begeistern. Es bringt alles mit, was man sich für ein Softwareprojekt nur vorstellen kann: angefangen bei einem Wiki über Bug/Feature Tracker bis hin zur Gantt-Darstellung der Aktivitäten. Dabei ist die Installation auf einem Debian Server denkbar einfach.

Zunächst benötigt man Ruby in Version 1.8.6 oder 1.8.7 - die Installation erfolgt einfach mittels

apt-get install ruby

Dann sollte man die Abhängigkeiten für die Installation von redmine erfüllen. Hierzu müssen die Ruby Gems installiert werden:

wget rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz

tar xvf rubygems-1.3.5.tgz

cd rubygems-1.3.5

ruby setup.rb

gem update --system

Und dann können noch die einzelnen Gems installiert werden.

gem install rails -v=2.3.5

gem install rack -v=1.0.1

gem install i18n -v=0.4.2

gem install mysql

Jetzt soll der MySQL-Benutzer und die Datenbank für Redmine angelegt werden. Am einfachsten kann man das mit phpMyAdmin erledigen, falls das nicht zur Verfügung steht, können die MySQL Kommandos in der Installationsanleitung verwendet werden.

Nun können wir uns endlich Redmine selbst widmen. Zunächst lädt man das Archiv mit den Daten herunter und entpackt sie in dem gewünschten Verzeichnis.

wget rubyforge.org/frs/download.php/73900/redmine-1.1.0.tar.gz

tar xvf redmine-1.1.0.tar.gz

cd redmine-1.1.0

Den zuvor mit MySQL erstellten Zugang trägt man in die Konfigurationsdatei im Ordner config/database.yml ein (dazu einfach die database.yml.example kopieren und umbenennen).

production:
  adapter: mysql
  database: redmineDbName
  host: localhost
  username: redmineDbUser
  password: redmineDbPassword

Natürlich müssen hier die zuvor erstellten Daten zu Datenbank, Username und Passwort eingetragen werden. Im Redmine-Verzeichnis führt man nun den Befehl zum Generieren eines Session Store Secrets aus. Anschließend kann die Datenbank befüllt werden.

rake generate_session_store

RAILS_ENV=production rake db:migrate

RAILS_ENV=production rake redmine:load_default_data

Der letzte Befehl fügt Standardeinträge in die Datenbank ein. Damit muss man nicht alles von Grund auf einrichten. Wer dies nicht will, kann das also auch auslassen.
Nun müssen noch die richtigen Verzeichnisberechtigungen gesetzt und ein Ordner für Plugin-Dateien angelegt werden.

mkdir tmp public/plugin_assets

sudo chown -R www-data:www-data files log tmp public/plugin_assets

sudo chmod -R 755 files log  tmp public/plugin_assets

Sind alle Schritte erledigt, kann die Redmine-Installation zum ersten Mal getestet werden.

ruby script/server webrick -e production

Ab jetzt kann man im Browser die Adresse http://localhost:3000/ aufrufen und sich mit
Benutzer: admin
Passwort: admin
in der Instanz von Redmine anmelden.

Weitere Konfigurationsanleitungen wie etwa die Einrichtung des E-Mail Versands oder die Verwendung von Redmine über Apache finden sich auf der Projektseite unter HowTos.

# sends an email upon login
echo -e "Login of `whoami` on `hostname` `date`\n`who`" | mail -s "Login of `whoami` on `hostname` `who | awk '{print $5}'`" email@adresse.org

(Zuerst erwähnt in Ausgabe 07/10, dann "verschönert" durch einen Leserbrief in 08/10.) Diese wenigen aneinandergehängten Befehle tun nichts anderes, als eine E-Mail an eine beliebige Adresse zu versenden, mit den Informationen zum momentan angemeldeten Benutzer. Trägt man das in eine Systemweite Include-Datei wie /etc/profile oder /etc/bash.bashrc ein, wird das Schnipsel zum Login ausgeführt, und der (zugegebenermaße, leicht paranoide) Administrator erfährt sofort, wenn sich jemand anmeldet.

Das kann natürlich auf Systemen, die hoch frequentiert sind, leicht zu einer Spam-artigen E-Mail-Schleuder werden, jedoch bietet es etwa für Server, auf denen sich eigentlich niemand fremder einloggen soll, ein gewisses Gefühl der Sicherheit immer zu wissen wenn sich jemand anmeldet.

Neu ist unter Anderem, dass sowohl die Desktop als auch die Netbook Variante zusammen auf einem ISO Abbild zur Verfügung stehen. Des Weiteren gab es grobe Usability-Verbesserungen beim grafischen Installer und bei KPackageKit, dem bevorzugten Softwaretool unter Kubuntu. Der Standardbrowser ist jetzt der auf WebKit basierende Rekonq, Konqueror und ein Installer für Firefox stehen nach wie vor zur Verfügung. Dieses Release wartet auch mit einer neuen Schriftart für das User Interface auf.

Für die Netbook-User bestimmt interessant ist das neue Hauptmenü für Programme, welches sich jetzt anstatt in einer eigenen Menüleiste ganz oben links in der Kontrollleiste als Menü öffnen lässt. Dieses viel-gewünschte Detail spart weiteren Platz auf dem Bildschrim, der bei Netbooks und ähnlichen Mobilgeräten sowieso knapp ist. Erstmalig gibt es auch als Technology Preview die Mobilversion der Plasma-Oberfläche, die in erster Linie für Smartphones mit Touch-Interface gedacht ist.

Zusammen mit allen anderen Verbesserungen, die auch im Hardwarebereich vor allem unter der Haube stattgefunden haben, ist dies sicher ein sehr gutes, aktuelles und empfehlenswertes Linux.

Nun kann es aber vorkommen, dass Webbrowser auf diesen Geräten nicht immer alles so darstellen, wie es eigentlich gedacht ist. Und solange wir noch keine weit verbreitete Version von Firefox für Mobilgeräte haben, wird das auch noch einige Zeit ein Problem bleiben. Aber nicht nur die richtige Darstellung ist ein Faktor für mobiles Browsen, auch der begrenzte Platz am Bildschirm stellt oft ein Hindernis dar.

Nun gibt es mehrere Möglichkeiten, auf Mobilgeräte optimierte Versionen einer Webseite anzubieten, die wie immer nur in Kombination zum Erfolg führen.

In CSS 2.1 werden die sogenannten Meda Types spezifiziert. Diese erlauben es, spezifischen Geräten eigene Stylesheets zuzuordnen. Beispielsweise spricht der Typ 'screen' auf normale Bildschirme und ähnliches an, während 'handheld' in der Theorie für kleinere Geräte wie Smartphones und Handys gedacht ist. Es gibt auch noch andere Media Types, etwa für die Darstellung bei einer Projektion oder für textbasierte Konsolen. Das ist zwar alles schön und gut, jedoch beachten viele Browser auf Mobilgeräten die vor Kurzem auf dem Markt gekommen sind, den Typ 'handheld' nicht, sondern verwenden die für die "richtigen" Browser gedachten 'screen' Stylesheets. Mit Opera Mini beispielsweise lässt sich dieses Verhalten im Menü festlegen, aber etwa beim iPhone oder einem Samsung Galaxy kann man nicht einmal wenn man es wollte etwas dagegen unternehmen.

Jetzt könnte man natürlich eine JavaScript-basierte Lösung entwickeln, oder serverseitig anhand des vom Browser mitgesendeten User Agent String eine Unterscheidung vornehmen und immer nur die zutreffenden Stylesheets ausliefern. Das ist sicher sinnvoll, aber es lässt sich auch durch eine weitere, neuere Methode ergänzen.

CSS 3 Media Queries lautet hier das Stichwort. Dies ist eine Erweiterung des Media Types aus CSS 2.1 welche es erlaubt, verschiedene Bedingungen abzufragen, und anhand dessen zu entscheiden, welches Stylesheet verwendet werden soll. Darunter fallen z.B. Breite, Höhe, Orientierung des Gerätes, Auflösung, Verfügbarkeit von Farben und Seitenverhältnis. Einige Beispiele finden sich auf den Seiten des w3c und hier gibt es einen sehr ausführlichen Artikel zu dem Thema. Diese Methode funktioniert natürlich nur mit Browsern, die diesen Teil von CSS 3 bereits unterstützen und ist daher vorerst nur als Ergänzung sinnvoll, hat aber einiges an Potential und findet mit ziemlicher Sicherheit in Zukunft weitere Verbreitung.

Unter Erweiterungen > Erweiterungen installieren in der Kategorie Front-End Plugins muss "Indexed Search Engine" installiert werden. Während der Installation wird das Manual als Abhängigkeit mitinstalliert. Will man die Suche auf Deutsch haben, muss im Anschluss auch noch die Übersetzung von Erweiterungen > Übersetzungen installiert werden. Lädt man jetzt das Backend neu, so fällt im Menü unter dem Punkt Adminwerkzeuge der neue Eintrag Indexierung auf. Hier kann man sehen wie viele Seiten bereits im Index vorhanden sind und des Weiteren auch welche Seiten mit welchen Parametern aufgerufen worden sind. Unter Web > Info gibt es auch zwei neue Einträge, die einerseits alle Begriffe einer Seite auflisten, mit der sie im Index steht und auch alle Suchbegriffe, die im Suchfeld verwendet wurden um zu suchen.

Bisher werden die Seite allerdings noch nicht indiziert. Erst muss dafür im Template Setup folgendes eingetragen werden. (Detaillierte Konfigurationsoptionen, die über das reine Aktivieren der Suche hinaus gehen, entnimmt man dem Manual.)

# Indexed Search
config.index_externals = 1 # Dokumente indizieren
page.config.index_enable = 1 # Seiten indizieren

Am Besten erstellt man für die Suche eine eigene Seite. Auf dieser kann man dann das Suchformular einfügen. Dieses befindet sich in Neuen Seiteninhalt > Allgemeines Plugin > Erweiterung: Indexsuche. Wünscht man ein Suchformular auf jeder Seite, kann ich nur empfehlen das so zu lösen, wie es im neuen Introduction Package von Typo3 gelöst ist. Es wird ein einfaches Input Feld erzeugt, welches auf die Seite mit der Suche weiterleitet und den Suchbegriff übergibt. (TS Setup:)

# Create the searchbox in TypoScript, so we can easily include in on every page
lib.searchbox = COA

# Make the searchbox remember the search term on the search result page
[globalVar = TSFE:id = 168]
lib.searchbox = COA_INT
[global]

lib.searchbox {
  stdWrap.prefixComment = 2 | lib.searchbox
  10 = TEXT
  10.typolink.parameter = {$plugin.tx_indexedsearch.searchpageID}
  10.typolink.returnLast = url
  10.wrap = <form action="|" method="post" id="indexedsearch"><fieldset>
  20 = COA
  20 {
    10 = TEXT
    10.data = GP : tx_indexedsearch |sword
    10.htmlSpecialChars = 1
    10.wrap = <input name="tx_indexedsearch[sword]" value="|" id="inputText" type="text" />
    20 = COA
    20 {
      10 = TEXT
      10.value = <input type="image" src="{$filepaths.templates}images/bg_searchButton.png" id="inputButton" alt="Search" title="Search" />
      20 = TEXT
      20.value = <input type="hidden" name="tx_indexedsearch[sections]" value="0" />
      30 = TEXT
      30.value = <input name="tx_indexedsearch[submit_button]" value="Search" type="hidden" />
    }
  }
  
  wrap = |</fieldset></form>
}
  

Nun kann man im Template an der Stelle, wo das Suchfeld erscheinen soll, einfach lib.searchbox zuweisen: 

page.10.marks.SEARCH < lib.searchbox

Will man den Bereich einschränken, der auf den Seiten durchsucht wird (etwa um Menüs oder Footer mit immer gleichem Inhalt von der Suche auszunehmen), können spezielle HTML Kommentare in das Seitentemplate eingefügt werden. Die Suche beachtet dann nur den Inhalt, der zwischen diesen Kommentaren steht:

<!--TYPO3SEARCH_begin-->
Inhalt, der durchsucht werden soll
<!--TYPO3SEARCH_end-->

Wichtig zu beachten ist, dass nur Seiten in den Index aufgenommen werden, auf denen das Typo3 Frontend Cache aktiviert ist. Also auch wenn beispielsweise tt_news verwendet wird, muss für dieses Plugin das Cache aktiviert werden.
Eine globale Einstellung, die den no_cache Parameter deaktiviert und somit jede Seite unabhängig von etwaigen Einstellungen cachen lässt, befindet sich im Installer unter All Configuration: [FE][disableNoCacheParameter]
Bevor man allerdings diese Einstellung setzt, sollte man den Beschreibungstext lesen, und für sich selbst herausfinden, ob das so für die betreffende Seite sinnvoll ist. Mir hat es geholfen, da bei einem Projekt mit tt_news die Einzelansich nicht gecached (und damit nicht indiziert) wurde, die falsch konfigurierte Option aber nirgends zu finden war...

Es wurde auch schon langsam notwendig, denn durch das Update der tt_news Extension auf Version 3.x haben sich die Eingabefelder im Backend verändert, wodurch beim Umstellen von einem Newseintrag auf einen Blogeintrag manche Felder plötzlich verschwanden. Auch konnte die Extension ve_guestbook - eigentlich als Gästebuch gedacht, jedoch für die Kommentare im Blog genutzt - mit ihren nur limitierten Möglichkeiten zur Spam-Bekämpfung kaum mehr mit einem modernen Blog mithalten.

Dank der neuen Timtab Version, die man sich momentan noch aus dem SVN Repository holen muss, gehören diese Probleme der Vergangenheit an. Timtab wurde an die Backend-Struktur der neuen Version von tt_news angepasst und anstatt ve_guestbook wird jetzt auf die Extension 'comments' gesetzt, die vom Design her schon darauf ausgelegt ist, für andere Extensions Kommentare zu liefern. Die alten Kommentare lassen sich auch ganz einfach mit einer anderen Extension 'vegb2cmnt' migrieren. (Nach getaner Arbeit kann man diese einfach wieder entfernen.)

Das einzige, wobei man etwas aufpassen muss und was noch etwas handarbeit erfordert, sind einige wenige Template-Tags, die sich geändert haben. Aber hier hilft einem schnell die neue Dokumentation. Es ist auch kein Problem, das vorhandene ve_guestbook Template an die comments Extension anzupassen. Dafür kann man auch gleich ein captcha, wie es etwa die Extension 'sr_freecap' liefert, verwenden. Dies wird einfach beim Einfügen des Datensatzes auf der Seite ausgewählt. (Details werden ausführlich in der Dokumentation von comments erläutert.)

Man kann nur hoffen, dass weiterhin so gute Arbeit geleistet wird, und dass wird bald eine Timtab Version 1.0 im TER sehen werden.

"FLOW3 brings new concepts to the PHP world. Domain-Driven Design, Dependency Injection and Aspect-Oriented Programming are some of them. And besides some great features we offer a new view on the "how" of software development. It's about efficiency.

It's about the beauty of code. And it's a lot of fun."

Um sich diese neuen Konzepte schon jetzt in Typo3 Extensions zu Nutze machen zu können und sich auf die neue Umgebung vorbereiten zu können (und weil 'Neu' einfach cool ist), gibt es besagte Erweiterungen 'extbase' und 'fluid'. Extbase stellt quasi das Interface zwischen Typo3 und der Flow3 API dar. Es erlaubt dem Programmierer seine Erweiterungen auf die "neue" Art zu schreiben und im "alten" Typo3 zu verwenden, als seien es normale Extensions. Und da man für ein neues Framework auch eine neue Art braucht Templates zu schreiben, übernimmt diesen Teil Fluid. Mit Fluid werden HTML-ähnliche Templates erstellt, die mit Fluid-spezifischen Tags versehen werden. Diese werden von ViewHelpern gerendert. Damit ist jetzt ein für alle Mal die Ansicht von der Logik dahinter getrennt.

Möchte man das ganze einmal ausprobieren, gibt es bereits die Extension 'blog_example', die mit Extbase und Fluid geschrieben wurde. Diese implementiert einen einfachen Blog; mit Posts, Kommentaren und was nicht sonst noch. Besonders interessant ist in dieser Beispiel-Extension die neue Verzeichnisstruktur zu beobachten, welche nicht nur Model, View und Controller beinhaltet, sondern auch gleich alle Resourcen wie Stylesheets, Konfiguration und Bilder eingeplant hat.

Es gibt auch bereits eine Extension, die einfach ein Gerüst zum Weiterarbeiten mit Extbase bereitstellt. 'efempty' enthält nur einen Controller mit einer Action und ein View und kann sonst gar nichts. (Wahrscheinlich war da jemand zu Faul jedes Mal die Verzeichnisstruktur anzulegen und die Dateien zu schreiben ;-) )

Momentan noch in Arbeit ist ein Kickstarter für Extensions mit Extbase/Fluid. Meines Wissens wird dieser gerade auf ExtJS umgeschrieben, um im Backend eine einheitliche JavaScript Bibliothek zu verwenden, aber für erste Versuche kann man bereits die Version im trunk des Repositorys auf Typo3 Forge verwenden. Hierzu modelliert man die Struktur der Extension per Drag&Drop, ähnlich einem UML Klassendiagramm, aus dem der Kickstarter dann den entsprechenden Code erzeugt. Die aktuelle Version verhält sich zwar nicht immer ganz brav, aber wenn man bereit ist auf die Suche nach Fehlern zu gehen, erspart er einem immerhin das anlegen der Files der Extension.

Für alle weiteren Experimente mit Extbase und Fluid sei die Dokumentation sowohl auf Typo3 Forge als auch die von Flow3 zu empfehlen. Vom Typo3 Sponsor mittwald.de gibt es sogar ein Walk-Through zur Erstellung einer Extension mit ausführlichen Erklärungen zu den neuen Konzepten und einer Referenz zu Fluid. Auch das Wiki von Typo3 enthält schon einige gute Informationen zur Thematik, will aber noch dringend erweitert werden *hint*.