Kanban [1] ist ein relativ neues, schlankes Vorgehensmodell zum einfachen Verwalten von Entwicklungsprozessen. Man hat sich dabei die Grundprinzipien der – ursprünglich von Toyota für die Automobilindustrie entwickelten – „Lean Production“ zum Vorbild genommen und versucht, diese Prinzipien auf die Software-Entwicklung zu übertragen. Die wichtigsten Ideen daraus:

• Es soll eine gleichmäßige Arbeitsbelastung geschaffen werden. Engpässe und Lastspitzen sind zu vermeiden, da sie den gesamten Prozess verlangsamen. Alles ist „im Fluss“.
• Produktionsfaktoren und Mitarbeiter müssen aus-, aber nicht überlastet sein. So lässt sich die Produktivität erhalten.
• Nur der Nachschub wird extern organisiert („push“), in ihrem Aufgabenbereich arbeiten die Teams jedoch eigenverantwortlich und weisen sich Aufgaben selbst zu („pull“).

Einsatzgebiet

Sobald ein Projekt ausgeliefert wurde, beginnt dessen Nachbetreuung, also die Support- und Maintenance-Phase. Diese ist gekennzeichnet durch viele kleine, kurz getaktete, oftmals unzusammenhängende Arbeitspakete von unterschiedlicher Priorität und Dauer. Aufgaben werden gern per Bugtracker-Ticket, Mail oder schlimmstenfalls mündlich zugewiesen.

Typischerweise befinden sich außerdem noch weitere Projekte in dieser Phase. Eine unübersichtliche Situation also, die sich kaum effektiv organisieren oder zumindest kontrollieren lässt. Und weder Scrum noch das alte Wasserfallmodell helfen hier weiter, da der Overhead beider Methoden einfach zu groß ist. Allein die Planungsdauer einer Sprintphase kann bereits den Umfang eines Arbeitspakets überschreiten. Hier nun liegen die Stärken von Kanban.

Funktionsweise

Das zentrale Element in Kanban ist das so genannte Kanban-Board, ein Whiteboard, auf das alle Mitarbeiter Zugriff haben. Das Board ist in verschiedene, frei definierbare Spalten aufgeteilt, die den Workflow des Entwicklerteams visualisieren. In diesen Spalten landen anschließend Arbeitspakete, die auf Karten notiert und priorisiert werden. Das Entwicklungsteam bedient sich anschließend selbst („Pull“ statt „Push“) und arbeitet so Paket für Paket ab. Ist eine Aufgabe erledigt, wandert das Paket eine Spalte weiter.

Was ein Paket ist, bestimmt das Team. Ebenso die Hürden, um von einer Spalte in die nächste zu kommen: Wichtig sind einheitliche Kriterien. So kann ein Paket alles sein, was länger als zwei Stunden und weniger als zwei Tage zur Umsetzung benötigt. Und als erledigt gilt ein Paket womöglich dann, wenn es tatsächlich ins Produktivsystem gespielt wurde. Auf diese Art lässt sich auch ein großes Arbeitspaket von mehreren Tagen Aufwand ganzheitlich nachverfolgen – von der Analyse bis zum Rollout.

Ein Kanban-Board visualisiert die einzelnen Prozesschritte und ihren Status.

Trotz geringer Reglementierung – ein Grundsatz Kanbans muss immer gelten: Jede Spalte hat ein eigenes „Work in Progress“-Limit (WiP-Limit), das nicht überschritten werden darf. Das WiP-Limit legt fest, wie viele Arbeitspakete sich gleichzeitig in einem Prozessschritt befinden dürfen. Es bestimmt sich somit aus der Entwicklungskapazität des Teams und verhindert damit dessen Überlastung. Auch Engpässe im Prozess fallen sofort auf. Ein Arbeitspaket, das partout nicht abgenommen wird, sorgt demnach für Stau in den vorhergehenden Schritten – in der Lehre des Kanban, die alles „im Fluss“ halten und gleichmäßig bewegen will, stellt das ein Problem dar, dem man sich umgehend annehmen muss.

Messtechnik

Kanban bietet vielfältige Metriken, um die Leistung eines Teams zu messen oder Flaschenhälse im Prozess aufzuspüren. So lässt sich etwa feststellen, wie lange ein Arbeitspaket braucht, um den gesamten Workflow zu durchlaufen („Cycle Time“). Diese Zahl stellt im Durchschnitt und auf alle Pakete gerechnet nichts anderes als die Entwicklungsgeschwindigkeit des Teams dar.

Ein „Cumulative Flow“-Diagramm hingegen deckt auf, in welchem Prozessschritt Engpässe auftreten und sich Arbeitspakete stauen. Dazu wird die Summe aller Pakete pro Prozessschritt in Abhängigkeit der Zeit gemessen. So kann man gezielt gegensteuern, indem man etwa das Abnahme/Testing-Team aufstockt, falls es bei der Abnahme immer wieder zu Verzögerungen kommt.

Ein Cumulative-Flow-Diagramm macht Engpässe sichtbar – zu sehen an den Stellen, an denen die Linien stärker auseinander laufen.

Das Verwalten mehrerer Projekte ist ebenfalls problemlos zu bewerkstelligen, ohne für jedes Projekt ein neues Whiteboard aufstellen zu müssen. Dazu gibt es zwei unterschiedliche Ansätze: Ergänzt man das Board um weitere Zeilen („Swimlanes“), lassen sich diese jeweils einem bestimmten Projekt zuordnen. Alternativ sind Kanban-Karten in verschiedenen Farben gebräuchlich.

Für unterschiedliche Projekte eignen sich entweder unterschiedlich gefärbte Karten oder eigene Zeilen auf dem Whiteboard.

Auch online lässt sich das Kanban-Modell visualisieren. Entsprechende Werkzeuge wie Greenhopper [2] oder das Kanban-Tool [3] sind aufgrund des zeit- und ortsunabhängigen Zugangs besonders bei verteilten Teams an unterschiedlichen Standorten sinnvoll.

Fazit

Nach einem Jahr Kanban-Nutzung in der Wartungsphase fällt das Urteil des Autors durchwegs positiv aus: Denn so simpel das Prinzip auch ist, in der Praxis zeigen sich verblüffende Effekte, sobald sich das Team darauf eingestellt hat. Durch die zentrale Bündelung aller Aufgaben am Kanban-Board gerät nichts in Vergessenheit.

Arbeitspakete werden nicht mehr per Mail oder gar auf Zuruf verteilt, sondern strukturiert erfasst und im Kontext der anderen Projekte betrachtet, was die Koordination der verschiedenen Aufgaben erheblich verbessert. Entwickler können sich endlich wieder auf die Entwicklung konzentrieren, anstatt ihre anstehenden Aufgaben verwalten zu müssen. Die WiP-Limits vermeiden indes eine Überlastung und störende Kontextwechsel zwischen verschiedenen Aufgaben. All das hat für erheblich mehr Ruhe und Konzentration im sonst hektischen Entwickleralltag gesorgt.

Aber auch das Projektmanagement profitiert von Kanban: Ein einziger Blick auf das Board sorgt für Transparenz und bringt einen schnellen Überblick. Wie hoch ist die Auslastung? Wer arbeitet gerade an welcher Aufgabe? Was steht als nächstes an? Aufwändige Status-Meetings und Nachfragen reduzieren sich von selbst auf ein kurzes, tägliches Stand-Up-Meeting vor dem Board. Die Arbeitsplanung und umständliche Lokalisierung freier Entwicklerkapazitäten wird vereinfacht, da letztlich nur noch Karten ans Board gepinnt werden müssen

Unterm Strich sorgt Kanban damit für eine höhere Mitarbeiterzufriedenheit und Produktivität, obschon das System (fast) ohne Regeln auskommt. Henrik Kniberg, Kanban-Evangelist, bemerkt dazu lapidar: „Just inches from „Do whatever“, but still surprisingly powerful“ [4]. Recht hat er.

Der Autor

Daniel Haller studierte in Darmstadt Media System Design, wo er 2009 diplomierte. Seitdem arbeitet er als Technischer Manager und Entwickler bei der Frankfurter Agentur BlueMars.

Ob Furzkissen-App oder die fünfundzwanzigste Taschenlampen-App, die Sinnhaftigkeit solcher Applikationen stellen nicht nur Entwickler, sondern mehr und mehr vor allem die Nutzer in Frage. Für jene, die ernsthafte Apps entwickeln, gilt: innovativ und neu, nutz- und gewinnbringend müssen sie sein. Bei über 300.000 Applikationen im iPhone App-Store machen Mehrwert, Nutzen genauso wie Usability den Erfolg künftiger Apps aus.

Dasselbe Spiel, eine andere Liga

Unabhängig von Idee und Plattform sind die Bedienbarkeit und damit die Akzeptanz der Nutzer entscheidend für den Erfolg einer App. Hierfür muss man sich von klassischen Webkonzepten lösen. Mobile Endgeräte stehen im Vergleich zu Desktop-Computern in einem völlig anderen Nutzungskontext. Wechselnde Lichtverhältnisse, akustische Beeinträchtigungen, Ablenkungen durch ein hektisches Umfeld sowie eine eventuell suboptimale Netzabdeckung sind da nur einige Faktoren, die man bei der Entwicklung mobiler Applikationen berücksichtigen muss. Aufgrund ihrer geringen Bildschirmgröße bieten Smartphones außerdem nur wenig Platz für Content und Bedienelemente. Diese veränderten Rahmenbedingungen diktieren die Anforderungen an das Konzept und die damit verbundene Usability einer mobilen Anwendung.

Groovende Apps

Setzt das Konzept auf bereits erlernte Interaktionsprinzipien und -elemente, mit denen der Nutzer durch sein jeweiliges Betriebssystem schon vertraut ist, findet er sich besser zurecht. Dadurch erleichtert man ihm den Einstieg schon ab der ersten Nutzung erheblich. Einen realen Mehrwert schafft das Einbeziehen von Funktionalitäten der Endgeräte. In der App-Gestaltung sollte man daher die gestenbasierte Steuerung auf Multi-Touch-Displays berücksichtigen.

Dazu zählen unter anderem doppeltes Antippen („Double-Tap“) oder Zoomen mit zwei Fingern („Pinching“). Die lagesensitive Steuerung ermöglicht dem Nutzer, sein Gerät vertikal oder horizontal zu halten, Inhalte passen sich entsprechend an. Ebenso birgt der Neigungssensor weitere ungeahnte Möglichkeiten. Die automatische Standortermittlung findet ihren Einsatz beim Auffinden von Personen, Orten oder Ereignissen in der Nähe.

Jedes Pixel zählt

Den geringen Platz richtig nutzen – eine Vorgabe, die durch die kleineren Bildschirmgrößen von mobilen Endgeräten eine Grundvoraussetzung für erfolgreiche Applikationen ist. Das heißt konkret, sich auf die essenziellen Funktionen zu konzentrieren und Inhalte zu reduzieren. Dabei kann der Einsatz eines Layouts mit nur einer Spalte helfen, das die gesamte Bildschirmbreite ausnutzt.

Obwohl Icons „small-screen-freundlich“ sind, da sie weniger Platz als Beschriftungen verbrauchen, ist es von entscheidender Bedeutung, dass die Nutzer diese auch verstehen. Um das Verständnis von Symbolen sicherzustellen, können kleine Textbeschreibungen unter dem Symbol stehen, speziell innerhalb einer Navigation. Dieser Kompromiss unterstützt unerfahrenere Nutzer, die mit dem Symbol weniger vertraut sind. Experten, die das Icon bereits kennen, werden dadurch jedoch nicht behindert. Ziel ist es, dass der Nutzer die App herunterlädt, öffnet und nutzt – ohne Erklärungen und ohne ein Herantasten. Applikationen für mobile Endgeräte müssen als „walk-up-and-use-system“ an den Markt gehen.

Die Kombination von Symbol und Text ist gerade bei der Navigation ein Gestaltungsprinzip, das dem Nutzer bereits bekannt ist.

Finger sind keine Mauszeiger

Konzepter müssen allerdings nicht nur eine Sichtbarkeit der Buttons und Links auf dem Touchscreen gewährleisten, sondern auch die Bedienung mit dem Finger optimal ermöglichen. Daher muss man bei der Konzeption die Bedienelemente in einer entsprechenden Größe und mit ausreichend Raum platzieren. Nur so minimiert man die Wahrscheinlichkeit einer falschen Berührung.

Everything as simple as possible

Auch die beste Tastatur eines Smartphones kann einer Computertastatur mit entsprechender Größe nicht das Wasser reichen. Anwender machen auf dem mobilen Endgerät weit mehr Fehler und sind langsamer beim Tippen. Daher sollte man Texteingaben innerhalb einer Applikation so häufig wie möglich vermeiden. Lösungen hierfür sind zum Beispiel, den Nutzern den Zugriff auf bereits gespeicherte Daten zu erlauben oder eine PIN statt eines Passworts zu verwenden. Eine innovative Form für den Input von Informationen besteht in der Verwendung von QR-Codes – sie sind nützlich und machen Spaß.

Gib mir Feedback

Direktes Feedback ist wichtiger als je zuvor. Nach einer Interaktion zwischen Nutzer und Applikation muss der Nutzer Feedback darüber bekommen, was gerade passiert beziehungsweise was bereits geschehen ist. Das fängt bei Ladevorgängen an und hört beim Tap auf eine Interaktionsfläche auf. Je nach mobilem Nutzungskontext ist die Internetanbindung nicht mit gleicher Qualität gewährleistet. Ein Ladekreisel unterstützt den User dabei zu verstehen, dass die Anwendung gerade im Hintergrund arbeitet. Die farbliche Veränderung bei Berührung einer Schaltfläche verdeutlicht, dass diese tatsächlich aktiviert wurde. Speziell bei Touchscreen-Geräten ist dieses Feedback von Bedeutung. Zusätzlich zur visuellen Rückmeldung eignen sich auch die gerätespezifischen Funktionalitäten, wie die Vibration. Diese Features sprechen gleich mehrere Sinne des Users an.

Durch die farbliche Veränderung bei Berührung einer Schaltfläche wird verdeutlicht, dass diese tatsächlich aktiviert wurde.

Nützliche Werkzeuge für erfolgreiche Konzepte

Die Anforderungen der Zielgruppen sind das A und O für den Erfolg einer Anwendung. Diverse Werkzeuge helfen dabei, sich den Anforderungen der Nutzer anzunähern und diese gleichzeitig dem Kunden zu vermitteln. Der Einsatz von Rollenmodellen (Personas) und Nutzungsszenarien (Use Cases) unterstützen dabei, sich in den Nutzer hineinzuversetzen und ihn greifbar zu machen. Für die Auswahl der konzeptionellen Tools gibt es kein Nonplusultra. Individuelles Eingehen auf Projekt und Auftraggeber ist unabdingbar. Die Auswahl ist abhängig von Abstraktionsfähigkeit und technischem sowie gestalterischem Background des Kunden. Ebenso ist der zeitliche Rahmen des Projekts ein Auswahlkriterium für die Art des zu liefernden konzeptionellen Ergebnisses.

Beim Bau einer CSS-Datei kommt es nicht selten vor, dass man für verschiedene Elemente ähnliche oder gar redundante Anweisungen vornimmt. Bestes Beispiel hierfür sind Farbangaben. Aber auch Angaben für Formatierungen, Abstände oder Größen weisen häufig Abhängigkeiten innerhalb einer oder mehrerer CSS-Dateien auf. Ein Programmierer würde hier wiederkehrende Elemente zentral definieren, Vorlagen verwenden und den eigentlichen CSS-Quellcode anschließend generieren lassen. Genau das ist der Ansatz von Syntactically Awesome Stylsheets (SASS) [1]. CSS-Stylesheets werden um Möglichkeiten erweitert, die Zusammenhänge zwischen verschiedenen Angaben in Form einer eigenen „Sprache“ notieren.

Eines der Ziele bei der Entwicklung der nächsten TYPO3-Generation 5.x (Codename „Phoenix“) war es, wo möglich auf Grafiken zu verzichten und gestalterische Elemente durch die reine Verwendung von HTML und CSS abzubilden. Dies erleichtert dann auch die einfache und zentrale Anpassbarkeit. Entsprechend verwundert es wenig, dass sich die Entwickler entschieden, die CSS-Angaben mit Hilfe von SASS aus zentralen Layout-Definitionen zu generieren.

Bei SASS existieren zwei verschiedene Syntax-Varianten. Die klassische Syntax (Dateiendung .sass) verzichtet auf Klammern und setzt stattdessen auf Einrückungen zur Gliederung von Elementen. Die ab SASS3 unterstützte „SCSS“-Syntax („Sassy CSS“, dt.: freches CSS, Dateiendung .scss) hingegen setzt auf CSS3, verwendet also Klammern und erweitert CSS um zusätzliche Möglichkeiten. Innerhalb eines Projekts ist es auch möglich, SASS- und SCSS-Syntax zu mischen. Je Datei findet aber jeweils nur eine Syntax Anwendung. Im Folgenden liegt der Fokus auf der SCSS-Syntax.

Erste Schritte

Das Werkzeug zur Umwandlung von SCSS/SASS-Code in CSS-Code selbst ist in Ruby geschrieben. Aber keine Angst: Wer das Tool nicht im Kern erweitern, sondern einfach nur nutzen möchte, benötigt keine Ruby-Kenntnisse. Nach Installation des Ruby-Gems „haml“ per „gem install haml“ ist das SASS-Tool auch schon für den ersten Einsatz bereit. Wer ein HAML-Paket seiner Linux-Distribution nutzen möchte, sollte beachten, dass dies die SCSS-Syntax erst ab Version 3.0 unterstützt.

Mit „sass style.scss:style.css“ ist die Konvertierung einer einzelnen Datei möglich. Alternativ können hier auch Quell- und Zielverzeichnis angegeben werden, die dann rekursiv abgearbeitet werden. Mit „sass --watch style.scss:style.css“ ist es außerdem möglich, einen Live-Modus zu aktivieren, bei dem die Quelldateien auf Änderungen beobachtet und die Zieldateien automatisch neu generiert werden.

Wie die Ausgabe aussieht, bestimmt das „--style“-Attribut. Standardmäßig aktiv ist „nested“; Einrückungen also, die die CSS-Hierarchie leserlich darstellen. Alternativ lassen sich die Angaben über „compressed“ auf das Nötigste reduzieren oder mittels „compact“ auf eine Zeile komprimieren.

Variablen

Jede gültige CSS3-Datei ist automatisch auch eine gültige SCSS-Datei. Ein zu Beginn häufig verwendetes Beispiel ist die zentrale Definition von Farben und Größenangaben mit Hilfe von Variablen. Diese werden in der Form „$variablenname“ angegeben, gefolgt von einem Doppelpunkt sowie dem gewünschten Wert, der selbst eine gültige CSS-Angabe ist. Auch ist es möglich, einfache mathematische Konstrukte wie Additionen oder Multiplikationen zu nutzen. Für diverse andere Anwendungen stehen sogar Funktionen bereit, etwa zur Berechnung von Farbwerten.

$dark-white: #f1f1f1;
$grey: lighten(#000000, 20%);
$light-grey: #9e9e9e;
$small-radius: 3px;
$mid-radius: 5px;

a.link-help {
	color: $light-grey;
}

div.button {
	width: 20px - 2*$small-radius;
}

Wiederkehrende Angaben lassen sich auch per „mixin“ auslagern und dann über „include“ an verschiedenen Stellen nutzen. Dabei ist die Angabe von optionalen Parametern möglich – ganz im Stil programmierter Funktionen.

@mixin rounded-corners-middle-right {
	-moz-border-radius: 0 $mid-radius $mid-radius 0;
	-webkit-border-radius: $mid-radius;
}

@mixin spacing($margin: 5px) {
	margin-right: $margin;
}

.errorMessages {
	@include rounded-corners-middle;
	@include spacing(10px);
	border: 1px solid #000000;
}

Verschachteln

Besonders hilfsreich ist die Verwendung von verschachtelten Angaben. Sie erleichtern den Überblick, geben den Definitionen klare Strukturen und ermöglichen auf einfache Weise beispielsweise die Umbenennung einer class-Angabe.

table.menu {
	background-color: blue;
	td.active {
		font-weight: bold;
		label {
			margin-left:10px;
		}
	}
}

div.headline {
	font: {
		weight: bold;
		size: 1.2em;
	}
}

table.menu { background-color: blue; }
table.menu td.active { font-weight: bold; }
table.menu td.active label { margin-left: 10px; }
div.headline { font-weight: bold; font-size: 1.2em; }

Vererben

.important {
	font-weight:bold;
}
.headline {
	font-size:1.2em;
}
.importantErrorheadline {
	@extend .important;
	@extend .headline;
	color: red;
}

Durch die Vererbung von einem oder mehreren Selektoren ist es möglich, selbst komplizierte Abhängigkeiten einfach und strukturiert abzubilden. Auch ist die Vererbung entlang einer Kette von Selektoren ist möglich.

.important, .importantErrorheadline { font-weight: bold; }
.headline, .importantErrorheadline { font-size: 1.2em; }
.importantErrorheadline { color: red; }

Auslagern und Einbinden

Wiederkehrende Werte und Definitionen werden bestenfalls bereits zu Beginn ausgelagert. Dies ermöglicht es, die im weiteren Verlauf eines Projekts üblicherweise stetig steigende Komplexität der CSS-Angaben auf ein überschaubares Maß zu reduzieren. Auch lassen sich so Module in verschiedenen CSS-Dateien zentral und einfach wiederverwenden. Dank mathematischer Ausdrücke und Funktionen lassen sich so Ursprungswerte wie die zu verwendende Bildschirmbreite zentral ändern und abhängige Werte automatisch neu berechnen.

@include „Dateiname“;

Beginnt der Dateiname mit einem Unterstrich, signalisiert dies SASS übrigens, dass die Datei nicht in eine eigenständige CSS-Datei zu konvertieren ist. Sie wird stattdessen lediglich als Modul innerhalb anderer Dateien genutzt.

Fazit

Die Möglichkeit beispielsweise Längen, Abstände und Farben zentral zu definieren erhöht die Übersichtlichkeit bereits enorm [2]. Verbunden mit mathematischen Operationen, Funktionen und wiederverwendbaren Blöcken wird es auf flexible Weise möglich, mit CSS-Angaben zu „programmieren“. Der Funktionsumfang lässt sich zudem durch andere Bibliotheken, etwa Compass [3], erweitern – sie bringen fertige Mixins, Vorlagen und eine wachsende Community. Durch die Generierung von standard-konformem CSS3 lässt sich SASS/SCSS außerdem ohne Anpassung mit allen Browsern nutzen.

Der Autor

Stefan Neufeind arbeitet als Experte für Webentwicklung und -administration bei der SpeedPartner GmbH in Neuss. Er ist Mitglied im TYPO3 Certification Team und engagiert sich in verschiedenen Open-Source-Projekten von PHP/PEAR bis hin zu OpenStreetMap. Außerdem ist er als Speaker auf Konferenzen zu Themen wie IPv6 und DNSSEC anzutreffen und als Autor für IT-Fachmagazine aktiv.

Bequem vom eigenen Sofa aus zu bestellen, scheint Volkssport geworden zu sein. Doch ob Besucher eines Onlineshops verweilen und schließlich einkaufen oder direkt wieder in den Weiten des Webs verschwinden, hängt von vielen Faktoren ab: Finden sie auf Anhieb, was sie gesucht haben? Erscheint der Shop vertrauenswürdig? Passen Preise für Produkte und Versand?

Hinzu kommt die Reaktionszeit der Seite, die einen großen Anteil am „Wohlfühlfaktor“ des Besuchers hat. Wenn der Nutzer den Eindruck hat, dass die Seite nur behäbig auf die Eingaben reagiert, macht das Surfen durch die Produkte des Shops nur wenig Spaß und der Einkauf wird bei Mitbewerbern fortgesetzt. Google wird deshalb in Zukunft die Ladegeschwindigkeit einer Seite stärker in seine Beurteilung innerhalb der Suche einbeziehen – ein weiterer Grund, ein Auge auf die Performance zu werfen.

Flexibilität als Fluch und Segen

Flexibilität galt bei Magento von Beginn an als Maxime. Über Module und Templates lässt sich das System sowohl funktional als auch optisch an fast alle Anforderungen und Ansprüche der Shopbetreiber anpassen. Nicht zuletzt dieser Flexibilität ist die hohe Beliebtheit Magentos zu verdanken.

Gleichzeitig erweist sich diese Flexibilität aber als größter Feind der Performance. Statt Prozesse, Daten und Layouts strikt festzulegen, bleibt dem Betreiber immer die Möglichkeit, Dinge anzupassen und zu erweitern. Dass das System hierdurch komplexere Routinen durchlaufen muss, ist die logische Konsequenz.

Bestes Beispiel hierfür ist das Entity-Attribute-Value-Pattern (EAV), das Magentos Datenmodelle hochgradig flexibel macht. Über das Backend können Betreiber Produkte frei mit beliebigen Attributen verschiedener Typen ausstatten. Die Besucher können dann Produkte anhand dieser Attribute vergleichen, filtern oder suchen.

Andererseits ist EAV sehr performancelastig. Im Gegensatz zu herkömmlichen Datenbankmodellen, bei denen die Eigenschaften eines Objekts in einzelnen Spalten einer flachen Tabelle gespeichert werden, teilt EAV die Daten in mehrere Tabellen auf: Entitätstypen wie Produkte, Kategorien oder Kunden werden zentral in der Tabelle eav_entity_type definiert. Attribute zu Produkten werden in eav_attribute spezifiziert und den jeweiligen Entitätstypen zugeordnet. Optionen für Auswahl-Attribute werden in eav_attribute_option, deren Labels in eav_attribute_option_value gespeichert. Die eigentlichen Daten der Produkte, Kategorien und sonstigen EAV-Objekte liegen aber in den Wertetabellen. Hierbei handelt es sich um eine Kopftabelle (beispielsweise catalog_product_entity) und bis zu neun datentypspezifische Tabellen für Integer, Texte, Datumswerte und andere.

Ganze fünf Tabellen sind nötig, um das Entity-Attribute-Pattern abzubilden; die Werte selbst, die das EAV komplettieren, fehlen in der Abbildung aus Platzgründen.

Um nun ein Produkt vollständig aus der Datenbank zu lesen, muss zunächst bestimmt werden, welche Attribute diesem Produkt zugeordnet sind, um anschließend die jeweiligen Werte auslesen zu können. Hierfür sind mehrere Datenbankzugriffe über mehrere Tabellen notwendig, was mehr Zeit und Ressourcen in Anspruch nimmt als der Zugriff auf eine einzelne Tabelle.

Ein weiteres Beispiel sind die Module: Über XML-Konfigurationen lässt sich das Verhalten anderer Module anpassen, indem beispielsweise Klassen dynamisch ausgetauscht werden. Hierdurch wird der Instanzierungsprozess von Klassen jedoch deutlich gebremst. Noch verstärkt wird dieser Effekt durch die vier Codepools „lib“, „core“, „community“ und „local“, durch die die Ordnung und Update-Fähigkeit des Systems gewahrt bleiben soll. Wird eine bestimmte Klasse gesucht, probiert das System die vier Ordner rückwärts durch. Dadurch wird das Laden der Klassen in Magento paradoxerweise schneller, je mehr Klassen in „local“ oder „community“ überschrieben werden.

Caching, Caching, Caching

Um Flexibilität und Performance unter einen Hut zu bringen, beinhaltet Magento diverse Caching-Mechanismen. Hierbei wird ausgenutzt, dass die meisten Konfigurationseinstellungen zu Beginn eines Projekts stark variieren, zur eigentlichen Produktivphase jedoch überwiegend gleich bleiben.

Eine Übersicht über die Zustände der Caches findet man im Backend bei System, Cache Management. Während es für die Entwicklungsumgebung durchaus sinnvoll sein kann, die Caches zu deaktivieren, ist dies in der Produktivumgebung keine Option. Innerhalb des Caching-Moduls finden sich folgende Optionen:

• Konfiguration: Beinhaltet die Grundkonfiguration des Systems sowie die Konfiguration aller aktiven Module.
• Layouts: Definition der Ausgabeblöcke sowie deren Positionen.
• Block HTML-Ausgabe: Speichert die HTML-Ausgaben von Blöcken, wenn diese für Caching konfiguriert wurden.
• Übersetzungen: Dieser Cache speichert die verschiedenen Übersetzungen zentral ab.
• Kollektionsdaten: Bestimmte Listen werden in Magento immer wieder aufgerufen. Werden diese zwischengespeichert, kann wertvolle Zeit gespart werden.
• EAV-Typen und -Attribute: Konfiguration der verschiedenen EAV-Elemente, sodass diese nicht permanent aus der Datenbank gelesen werden müssen.
• Konfiguration der Webdienste: Vorrangig für die SOAP-API interessant; speichert öffentliche Methoden und Zugriffsrechte.

Obschon überall zu Caching geraten wird, finden sich in der Praxis noch zu viele Magento-Shops mit (partiell) deaktiviertem Cache. Das ist zum Teil einer fehlenden Unterstützung durch Templates oder Erweiterungen von Drittanbietern geschuldet: Haben die Entwickler Caching bei der Programmierung nicht vorgesehen, beeinträchtigt dies unter Umständen die komplette Installation.

Cache-Keys

Ob Magento einen Block live generieren muss oder eine valide Version aus dem Cache beziehen kann, wird anhand so genannter Cache-Keys entschieden. Diese geben den aktuellen Zustand der Ausgabe wieder und werden vor der Ausgabe eines Blocks generiert.

Wird der aktuelle Zustand in einem gültigen Eintrag im Speicher gefunden, kann der dort hinterlegte Inhalt direkt ausgegeben werden, ohne weitere Programmlogik ausführen zu müssen. Wird der Block nicht im Speicher gefunden, erzeugt Magento die Blockausgabe und legt diese für die definierte Cache-Lebenszeit statisch ab. Ohne Cache-Informationen im Block kann das System die Blockausgaben nicht zwischenspeichern und erzeugt die Ausgaben bei jedem Zugriff dynamisch.

Die Definition der Cache-Angaben erfolgt in der Regel im Magento-eigenen Platzhalterkonstruktor des Blocks (Template Method Pattern).

class T3n_Example_Block_Example extends Mage_Core_Block_Template
{
	protected function _construct()
	{
		$this->addData(array(
			'cache_lifetime'	=> 86400,
			'cache_tags'	=> array(Mage_Catalog_Model_Product::CACHE_TAG)
		));
	}

	public function getCacheKeyInfo() {
		return array(
			'T3N_EXAMPLE',
			(int)Mage::app()->getStore()->isCurrentlySecure(),
			Mage::getDesign()->getPackageName(),
			Mage::getDesign()->getTheme('template')
		);
	}

}

Der angegebene Wert in der Cache-Lifetime definiert den Zeitraum in Sekunden, für den der Cache gültig sein soll. Der Wert sollte mit Bedacht gewählt werden. Fällt er zu niedrig aus, wird der Block zu häufig dynamisch generiert. Ist er zu hoch, kommt es zu keiner Aktualisierung und die Informationen bleiben länger im Speicher als gewünscht. Im Beispiel wird eine Cache-Lebenszeit von einem Tag (in Sekunden; 60 x 60 x 24 = 86400) definiert.

Die Cache-Tags unterteilen die Informationen im Cache in verschiedene Kategorien. Diese Kategorien werden etwa verwendet, um bestimmte Bestandteile gezielt zu aktivieren, zu deaktivieren oder zu verwerfen. Genau das passiert auch beim Löschen eines Caches über das Magento-Backend.

Im Backend lassen sich die einzelnen Caches überwachen und steuern.

Dritter Bestandteil des Listings ist die Definition des Keys in der Methode getCacheKeyInfo. Der Cache-Key ist der eindeutige Bezeichner für eine im Cache hinterlegte Information. Die Werte des Cache-Keys sollten alle verschiedenen Zustände eines Blocks wiedergeben, die einzeln gespeichert werden. Erlaubt ein Block verschiedene Zustände, so darf es genauso viele unterschiedliche Cache-Keys für den aktuellen Block geben. Um Cache-Kollisionen mit anderen Blöcken zu vermeiden, wird als erster Teil meist der Identifikator des aktuellen Blocks verwendet. Weitere Komponenten sind häufig das Package und Theme sowie die Sprache.

Cache-Backends

Wie die Caching-Daten gespeichert werden, entscheidet die Wahl der Cache-Backends, welche in der Konfigurationsdatei app/etc/local.xml eingestellt werden.

<config>
	<cache>
		<backend>memcached</backend>
		<slow_backend>database</slow_backend>
		<fast_backend>memcached</fast_backend>
		<memcached>
			<servers>
				<server>
					<host>192.168.0.1</host>
					<port>11211</port>
					<persistent>0</persistent>
				</server>
			</servers>
		</memcached>
	</cache>
	[...]
</config>

In <backend> wird das Cache-Backend eingetragen, welches mit der Zwischenspeicherung beauftragt werden soll. Mögliche Werte sind memcached, apc, xcache, eaccelerator, sqlite, database und file. Wird kein Wert übergeben, nutzt Magento standardmäßig den dateibasierten Cache.

Die vier erstgenannten Cache-Backends sind arbeits­speicher­basiert und dementsprechend schnell; allerdings sind sie nicht persistent und unterstützen keine Cache-Tags. Sie werden deshalb im Rahmen des Two-Level-Cache-Backends mit einem langsameren, aber persistenten Speicher kombiniert. Dies geschieht über die Konfigurations-Tags <slow_backend> und <fast_backend>. Darüber hinaus werden dem memcached-Backend im Beispiel noch notwendige Serverinformationen übergeben.

Zur Verbesserung der Two-Level-Cache-Performance existiert ein Cache-Modul [1], welches verhindert, dass Magento bei jedem Lesezugriff den schnellen Cache neu schreibt. Über das Modul kann zusätzlich das Cache-Backend Libmemcached aktiviert werden, welches in den Benchmarks deutlich besser abschneidet als Memcached [2].

Empfohlen wird für einzelne Webserver übrigens APC mit File-Cache. Werden mehrere Webserver verwendet, sollte das Libmemcached- mit dem Datenbank-Backend kombiniert werden.

Von all den Techniken, Spielereien und Trends, mit denen wir Webworker uns in den letzten zehn Jahren beschäftigen durften, ist insbesondere eine bei allen Nutzern angekommen: Suchmaschinenoptimierung (SEO). Selbst wenig internetaffine Kunden fragen von sich aus nach SEO. Bessere Platzierungen versteht jeder und verlangt es dann auch für die eigene Webseite. Auch Barrierefreiheit hält langsam, aber sicher Einzug in den Webworker-Alltag. Firmen, die gesetzlich nicht dazu gezwungen sind, fragen beim Relaunch von sich aus danach – zumindest ab und zu. Ich meine: HTML5, CSS3 und all die anderen neuen Techniken sind erst dann im Mainstream angekommen, wenn Kunden direkt danach fragen.

Webworker bevorzugt

All die Aktionen, um HTML5 und CSS3 zu promoten, richten sich bisher vornehmlich an Webworker: Apples HTML5 Showcase [1], Chrome Experiments [2], Mozillas Showcase Web O'Wonder [3], der HTML5 Doctor [4] oder Dive into HTML5 [5]. Das ist natürlich legitim, denn zunächst müssen erst einmal genügend Browser die Techniken unterstützen und Webworker müssen wissen, wie sie die Techniken einsetzen können.

Die neuen Techniken bringen bekanntlich native Unterstützung von Video und Audio, Geolocation, Drag & Drop, bessere Formulare, Super Cookies (Local Storage) und Canvas. Das ist toll. Wir wissen das. Wird Zeit, dass es unsere Kunden auch wissen. Und es nicht nur wissen, sondern auch fordern. Der nächste Schritt heißt also, Kunden den Mehrwert von HTML5 und CSS3 zu zeigen.

Der größte Ansporn, Webseiten auf HTML5 umzurüsten, war bisher Apples Flash-Verweigerung. Also mussten viele Webseiten eine Möglichkeit finden, ihre Videos trotzdem zeigen zu können und landeten bei HTML5. Aber eben nicht wegen der Vorteile von HTML5, sondern schlicht, weil Flash nicht funktionierte.

Zeit für Erfolgsstories

Noch ist es möglich, durch HTML5-Spielereien aufzufallen, die andere Webseiten noch nicht nutzen. Die Indie-Rock-Band The Gamits hat zum Beispiel einen ihrer Songs zum Download angeboten [6]. Dazu muss man jedoch zunächst ihr Video wieder zurechtpuzzeln. In den 3x6 Teilen läuft währenddessen das Video ab. Das ist eine hübsche Idee und nicht so leicht, wie es sich anhört; in gewissen Kreisen spricht sich das auch schnell herum.

Besser sind überzeugende Zahlenspiele. Nach dem Motto: Wir haben unsere Webseite umgestellt und erledigen alle runden Ecken, Schatten und Verläufe nun mit CSS3. Wir sparen damit x Kilobyte beim Laden der Seite, sie lädt schneller und wir haben y Prozent mehr Verkäufe. Oder: Seit unserer Usability-Optimierung mit Drag & Drop haben wir z Prozent mehr Umsatz erzielt.

Spätestens dann, wenn Suchmaschinen neue HTML5-Tags wie <article> und <section> auswerten und insbesondere, wenn RDF (Resource Description Framework) sich durchsetzt und in den Ergebnissen berücksichtigt wird, will jeder auf die neuen Techniken umstellen wollen. Warum nicht jetzt schon damit anfangen?

Wie die Botschaft letztlich konkret lautet, ist sekundär – die Webseite ist schneller; sie wird besser von Suchmaschinen indiziert; Kunden mögen unsere neuen Features und kommen gerne wieder. In jedem Fall muss die Botschaft aber lauten: Seit wir auf HTML5 umgestellt haben, verdienen wir mehr Geld. Und sobald wir die richtigen Erfolgsstories haben, wird HTML5 auch im Mainstream angekommen sein.

Der Autor

Nicolai Schwarz arbeitet als selbstständiger Designer und Webentwickler unter dem Namen textformer.de in Dortmund. Hauptsächlich beschäftigt er sich mit Drupal-Projekten für mittelständische Unternehmen. Nebenbei ist er als Redakteur und Autor bei den Webkrauts tätig. Zurzeit schreibt er an seinem ersten Fachbuch über Drupal 7.

Wer heute einen Hosting-Anbieter sucht, schielt meist mit einem Auge auf das Stichwort „Cloud“. Die Vorteile liegen auf der Hand: Statt Server-Kapazitäten zu horten, die man sowieso nur einmal im Jahr benötigt, verlagert man Applikationen zu einem Cloud-Hoster, der bei Bedarf fast unbegrenzte Rechenpower sofort und vor allem automatisch dazuschaltet.

Das Ganze läuft dann nach dem Modell „Pay as you use“. Laufen die Geschäfte gut, bezahlt man eben mehr für das Hosting, Auftragsdellen bei niedriger Server-Auslastung resultieren dagegen in niedrigen Rechnungen vom Hoster. Das Thema Kosten ist einer der Treiber für die Cloud-Begeisterung, denn auch hohe Anfangsinvestitionen entfallen. Das zieht verstärkt kleine und mittelständische Firmen an. Doch bis hierhin ist alles nur Theorie, Praxis-Check und Marktüberblick über Hosting-Angebote in Deutschland können die Entscheidung für die richtige Cloud erleichtern.

Ein Problem für alle, die einen Cloud-Hoster suchen, ist das unübersichtliche Angebot. Die Cloud ist auch für die Hosting-Anbieter cool, schließlich gehen die Preise für dedizierte und virtuelle Server seit Jahren runter und Shared-Hosting-Angebote locken niemanden mehr hinter dem Ofen hervor. Doch genau da liegt die Gefahr, denn jeder Anbieter hat seine eigene Interpretation vom Begriff Cloud. Manch cleverer Geschäftsmann fügt seinem Angebot einfach das Wort Cloud an und schon brummt das Geschäft.

So ist beispielsweise beim Dynamic Cloud Server von 1&1 nicht wirklich viel Cloud-Computing dabei. Im Angebot steckt ein dedizierter Server, den man über Virtualisierung mit Xen in engen Grenzen flexibel verwalten kann. Da man vorher genau wählen muss, wieviele CPUs man will und man ebenso per Schieberegler auch RAM- und Festplattenausstattung festzurren muss, ist die grenzenlose Skalierbarkeit nicht gegeben. Kunden können über eine zentrale Verwaltung zwar an diesen Stellschrauben drehen, automatische Bereitstellung von Ressourcen ist das aber nicht. Auch beim Bezahlmodell ist 1&1 wenig flexibel: Für den Server muss man wie beim klassischen Hosting Monatsgebühren entrichten. Dreht man an den Konfigurationsstellschrauben, dann sinkt oder erhöht sich der Preis im nächsten Monat. Unter dem Strich bekommt man bei 1&1 also einen guten Mix aus dediziertem und virtuellem Server, den man auf monatlicher Basis anpassen kann – Cloud Computing ist das aber nicht.

Echtes Cloud-Hosting

Nicht nur Anbieter kämpfen mit dem Begriff Cloud, auch die Kunden haben unterschiedliche Auffassungen und Bedürfnisse beim Cloud-Hosting. Einer Untersuchung von Deloitte zufolge interessiert sich jedes zweite deutsche Unternehmen nicht für öffentliche Cloud-Services und bevorzugt Private Clouds.

Viele Angebote in Deutschland laufen deshalb unter dem Stichwort „Dedicated Private Cloud“. Dahinter steckt eine dedizierte Server-Umgebung, in der der Kunde seine eigene Cloud betreiben kann. Demnach tummeln sich keine anderen Kunden in dieser Infrastruktur. Der Nachteil: Die Ressourcen sind eben nicht fast unendlich, sondern durch die dedizierte Umgebung stark begrenzt. Das Private-Cloud-Angebot ist ein Modell, das sich an Unternehmen richtet, die besonders großen Wert auf Sicherheit und Service legen.

Während bei Private Clouds eine dedizierte Server-Umgebung die Basis bildet, bucht man bei Public-Cloud-Angeboten Instanzen in der Cloud-Umgebung des Hosters.

 

Zur besseren Orientierung sollte man also zwischen „Echtem Cloud-Hosting“ und „Dedicated Private Clouds“ unterscheiden. Unter „echtes“ Cloud-Hosting fallen in der Übersichtstabelle (siehe nächste Seite) die so genannten Public Cloud Services wie Amazon EC2 oder CloudSigma. Hier stellt der Anbieter eine Cloud-Umgebung bereit, die er für seine Kunden am Laufen hält. Die Hardware, auf die die Unternehmen zugreifen, und sämtliche Software-Lizenzen sind Eigentum des Cloud Anbieters. Jeder Kunde holt sich das für ihn optimale Paket und betreibt auf dieser Basis seine Applikationen.

Man erkennt öffentliche Cloud-Services meist daran, dass der Anbieter nicht von Servern spricht, sondern von Instanzen mit einer bestimmten Rechenpower. Kunden kombinieren die Instanzen je nach Bedarf zu einem Ressourcen-Pool. Dass auf der Infrastruktur des Anbieters auch noch andere Kunden unterwegs sind, liegt in der Natur der Sache. Einschränkungen bei der Leistung muss man bei einem echten Cloud-Angebot aber nicht fürchten, die Skalierung on Demand und die automatische Bereitstellung von Rechenpower ist ja gerade der Clou.

Speziell bei der Suche nach Angeboten mit deutschen Rechenzentren wird das Feld schon sehr dünn, denn selbst Amazon hat als einzigen europäischen Standort ein Rechenzentrum in Irland im Angebot. Einzig JiffyBox von Domainfactory und die Cloud Services von Nionex haben einen öffentlichen Cloud-Service in einem deutschen Rechenzentrum am Start. Das interessante Angebot CCloud der Centron GmbH befindet sich noch bis Mitte des Jahres im Beta-Test, wird aber alle wichtigen Merkmale des Cloud-Hosting umsetzen.

Bezahlen im Minutentakt

Wer den richtigen Hoster finden will, kann die bereitgestellte Tabelle zur Orientierung heranziehen, sollte aber im Detail immer noch nachfragen oder zumindest vor dem Vertragsabschluss das Kleingedruckte lesen. Der Spielraum ist nämlich immens. So gibt es beispielsweise beim Bezahlmodell unterschiedliche Abrechnungsmodi. Am genauesten nimmt es derzeit CloudSigma, die jeden Fünf-Minuten-Abschnitt als Verbrauchseinheit abrechnen. Gängiger ist jedoch die Abrechnung pro Stunde, wie bei Amazon oder JiffyBox.

In der Praxis dürften außerdem die Punkte „Ausfallsicherheit“ und „Integriertes Backup“ oft den Ausschlag für oder gegen einen Hosting-Anbieter geben. Physikalische Sicherheit, also etwa Zugangssicherung und Feuerschutz, ist in den Rechenzentren der Anbieter Standard. Ebenso rüsten die meisten Anbieter ihre Server mit RAID-Systemen aus, die die Nutzdaten spiegeln. Bei einem Hardware-Defekt tauschen die Anbieter dann kaputte Festplatten ohne Datenverlust. Ausgefeilter und längst nicht in jedem Angebot enthalten sind Hochverfügbarkeits-Features – also ein Failover-Cluster, bei dem virtuelle Maschinen bei Hardware-Defekt bei laufendem Betrieb umgezogen werden. Diesen Service bieten nur die teuren Angebote von Amazon, Centron und Nionex. Die Ausstattung mit Backup-Features ist von Angebot zu Angebot verschieden. Manche Anbieter, etwa 1&1 oder Strato, bieten Speicherplatz für Backups an, der Kunde muss diese aber selbst einrichten. Andere Anbieter, beispielsweise Host Europe, sichern Kundendaten dagegen in festen Abständen automatisch.

Der richtige Anbieter

In der Tabelle finden sich drei Arten von Cloud-Hosting-Angeboten: Public Cloud Services, Dedicated Private Clouds und der Rest, der sich gewisse Aspekte vom Cloud-Computing borgt. Unternehmen, die eine dedizierte Umgebung wollen, weil ihre Sicherheitsanforderungen besonders hoch sind, sollten zur Private Cloud greifen. Wer personenbezogene Daten in der Cloud verarbeiten möchte, ist bei JiffyBox oder Nionex dank deutschen Rechenzentren und SLAs gut aufgehoben. Jenseits erhöhter Datenschutzbestimmungen bieten die Platzhirsche Amazon und CloudSigma das flexibelste Angebot am Markt, Ressourcen ohne Ende und preiswerte Stundensätze. Wer nur etwas flexibler als mit dedizierten Servern unterwegs sein will, sollte einen Blick auf die Angebote von 1&1, Incoweb und Strato werfen. Die bieten zwar kein Cloud-Computing nach scharfer Definition, aber das braucht auch längst nicht jedes Unternehmen.

Der Autor

Jörg Geiger ist Diplom-Informatiker und freier IT-Journalist in München. Neben der Cloud zählen insbesondere IT-Sicherheit, Betriebssysteme und mobile Systeme zu seinen thematischen Schwerpunkten.

Bei Änderungen an einem TYPO3-Webauftritt sieht der Arbeitsprozess häufig so aus: Anfangs versteckte Seiten werden generiert und mit Inhalt gefüllt. Diese Seiten erhält der Kollege per Mail, der das Ganze lesen und korrigieren soll, bevor es schlussendlich publiziert wird.

Viel eleganter und einfacher geht das mit einer Arbeitsumgebung, einem sogenannten Workspace. In diesem Workspace können beliebig viele Änderungen an der Webseite getätigt werden, ohne dass diese öffentlich zu sehen sind. Über einen entsprechend zu definierenden Prozess können die Änderungen dann korrigiert und publiziert werden. Benachrichtigungen per E-Mail mit individuellen Kommentaren der Redakteure unterstützen den Prozess. Je mehr Redakteure und komplexe Review-Prozesse involviert sind, desto mehr lohnt sich also auch ein Workspace.

Schritt für Schritt

Um Änderungen an einem Webauftritt zu tätigen, wechselt der Redakteur nach dem Backend-Login zuerst in den Workspace, ein Ebenen-Icon am rechten oberen Rand.

In diesem Workspace können dann beliebig viele Änderungen getätigt und kontrolliert werden, ohne dass diese auf dem Webauftritt sichtbar werden. Über eine spezielle Voransicht lassen sich die Änderungen bequem mit der Live-Version des Webauftritts vergleichen.

Ist der Redakteur mit den Änderungen zufrieden, sendet er die Änderung im Arbeitsprozess an die nächste Stelle. Dies ist über ein entsprechendes TYPO3-Modul möglich, in dem alle Änderungen verwaltet werden können.

Nun erhält der für diese Stelle zuständige Redakteur eine E-Mail – gegebenenfalls mit persönlichem Kommentar. In einem einfachen Schritt kann der aktuelle Redakteur nun, nach Kontrolle der Änderungen, diese freischalten.

Einfache Konfiguration

Es ist auch möglich, in der Workspace-Konfiguration weitere Kontrollpunkte einzurichten. Dank des detaillierten Berechtigungssystems lässt sich genau bestimmen, wer letztendlich Änderungen publizieren und somit den offiziellen Webauftritt verändern darf. Auch die Konfiguration des Arbeitsprozesses ist sehr flexibel, es lassen sich beliebig viele Prozessschritte mit individuellem Namen und entsprechenden Verantwortlichkeiten definieren. Was genau möglich ist und wie die einzelnen Prozesse definiert werden, lässt sich im Detail in der aktuellen Workspace-Dokumentation nachlesen [1].

Darüber hinaus lassen sich auch die Benachrichtigungs-Mails leicht anpassen. Die Nachrichten enthalten Informationen zu den Datensätzen, dem Redakteur und den entsprechenden Änderungen. Anpassen lassen sie sich in ihrem Informationsgehalt, den Empfängern und vor allem in ihrem Layout.

News und andere Datensätze

Datensätze, die von TYPO3-Extensions bereitgestellt werden (News, Kalender-Einträge etc.), können ebenfalls im Workspace gehandhabt werden, sofern der Entwickler dies bei der Programmierung berücksichtigt hat. Wenn man bei einer Extension von der „Unterstützung der Workspaces-Funktion“ spricht, so muss man allerdings zwischen zwei Aspekten unterscheiden. Es gibt zum einen die Unterstützung des Workspace-Backends, das heißt ein Datensatz kann im Workspace erstellt und dann Schritt für Schritt publiziert werden. Dies können Entwickler erreichen, in dem sie den Extension-Kickstarter nutzen.

Zum anderen gibt es die Vorschau-Funktion für den Datensatz, das heißt der Entwickler unterstützt die Workspace-Vorschau, sodass der Datensatz vorab betrachtet werden kann. Bei Extbase-Extensions ist dies von Haus aus vorgesehen und muss nicht extra programmiert werden. Bei piBase-Extensions gibt es einen kurzen Leitfaden auf den Entwicklungsseiten des Workspace-Projekts [2].

Alles hat Grenzen

TYPO3-Workspaces sind ein sehr mächtiges Werkzeug, sie haben aber auch Ihre Grenzen. So ist es nicht möglich, parallele Arbeitsschritte zu definieren, sondern alles bis hin zur Publizierung geht der Reihe nach vor sich. Auch eine automatische Revisionssicherheit ist durch die Nutzung von Workspaces nicht gegeben. Zuletzt ist es derzeit noch schwierig, Abhängigkeiten zwischen verschiedenen Änderungen, etwa Sprachübersetzungen, im Workspace zu handhaben.

Neuerungen in TYPO3 4.5

TYPO3 bietet seit langem die Workspace-Funktion, die Benutzeroberfläche wurde aber in der neuesten Version 4.5 komplett überarbeitet. Die Möglichkeit, beliebig viele Arbeitsschritte definieren zu können, ist genauso neu, wie die Workspace-Unterstützung für sogenannte IRRE-Datensätze. Die neue Vorschau rundet das Ganze ab und ermöglicht dem Redakteur eine bequeme Nutzung.

Weiterentwicklung

Für die nächste TYPO3-Version sind weitere Neuerungen geplant, wobei das Workspace-Team noch nicht entschieden hat, welche Neuerungen zuerst umgesetzt werden. Bereits im Review-Prozess sind kleinere Neuerungen wie die feinere Konfiguration der E-Mail-Benachrichtigungen oder ein Vorschau-Link direkt in der E-Mail.

Die Autorin

Sonja Scholz ist als TYPO3-Entwicklerin und Projektleiterin bei der Schweizer TYPO3-Agentur cab services ag tätig. Als Teamleiterin des TYPO3-Workspace-Teams hat sie die Workspace-Weiterentwicklung für TYPO3 4.5 unterstützt und koordiniert. In ihrer Freizeit entspannt sie bei einem guten Buch oder macht das Gelände als Cowgirl im Westernreiten unsicher.

Die Zahl der Websites nimmt kontinuierlich zu – was aber praktisch konstant bleibt, ist die Zahl der Ergebnisse einer Suchmaschine, die ein Nutzer wahrnimmt. Meist sind es nur die ersten zehn Resultate, die Relevanz haben. Schon die Ergebnisse auf den Plätzen 11 bis 20 nehmen nur noch etwa zehn Prozent der Nutzer wahr. Und auch auf der ersten Seite bekommen nur die Top Five viele Besucher.

Ein Betreiber, der geschäftlichen Erfolg anstrebt, kommt um eine Optimierung der Seite für Suchmaschinen nicht herum. Inzwischen hat sich ein beachtlicher Markt für Dienstleistungen im Bereich SEO (Search Engine Optimization) und SEM (Search Engine Marketing) entwickelt. Leider gibt es auch hier einige schwarze Schafe, die nur das Beste des Kunden möchten – sein Geld.

Qualität statt Quantität

Auch die Betreiber der Suchmaschinen haben ein Interesse an einer entsprechenden Optimierung, denn dadurch wird es einfacher, die Ergebnisse nach Relevanz auszugeben. Längst sind die Zeiten vorbei, in denen es darum ging, möglichst viele Suchergebnisse anzuzeigen. Heute zählen einzig und allein die richtigen Treffer. Idealerweise sollte der Nutzer auf jede Anfrage gleich die optimalen Ergebnisse bekommen, ohne dass er die Suche mehrfach eingrenzen und wiederholen muss.

Für Websites mit Zielgruppen im europäischen Markt genügt es, die Seiten für Google zu optimieren. Da sich jedoch die Algorithmen der Anbieter nicht wesentlich unterscheiden, ist es nicht erforderlich, für jede Suchmaschine eine spezielle Optimierung einzusetzen. Mit großer Skepsis sollte man daher auch Angeboten wie „wir tragen Ihre Seite in 500 Suchmaschinen ein“ begegnen. Die Offerten sind meist ihr Geld nicht wert.

Wichtige Parameter

Google bietet mit seinen Richtlinien für Webmaster [1] bereits viele Informationen für die Optimierung einer Website. Auch wenn es einige wichtige technische Regeln für den Aufbau einer Seite gibt, ist doch letztlich der Inhalt und Informationsgehalt einer Seite ausschlaggebend. Eine Strategie für die Verbesserung des Ranking muss daher auch die Redakteure einschließen, sie tragen mindestens 50 Prozent zum Erfolg bei (siehe auch Artikel ab Seite 54).

Neben Extensions für TYPO3 können Seitenbetreiber auch kostenlose Tools wie Firebug zur Optimierung der Performance nutzen.

Auch wenn angeblich 200 Faktoren in die Reihenfolge der Suchergebnisse eingehen, sind es nur eine überschaubare Anzahl von Parametern, die eine wichtige Rolle spielen. Man muss jedoch beachten, dass neue Faktoren dazu kommen und die Bedeutung anderer mit der Zeit abnehmen kann. Früher galt, dass der Keywords-Parameter bei den Metatags eine entscheidende Rolle spielt. Mit der Folge, dass viele Betreiber und Optimierer hier zu viel des Guten taten und teilweise bis zu 1.000 Schlüsselbegriffe eingetragen haben.

Manch einer meinte, mit Begriffen wie „Britney Spears“ zusätzliche Besucher für Seiten zum Thema Küchenutensilien generieren zu können. Schnell stellt der Suchende fest, dass die aufgerufene Seite nicht die gesuchte Information liefert und kehrt zur Ergebnisliste zurück. Das merkt auch Google: Wenn der Anwender ein zweites Ergebnis wenige Sekunden nach dem ersten Klick aufruft, war der zuerst gewählte Treffer wohl nicht relevant. Das führt, wenn es häufiger vorkommt, zu einer Herabstufung in den Rankings.

Google hat schon vor längerer Zeit bestätigt, dass die Keywords in den Metatags keinen Einfluss mehr auf das Ranking haben. Dafür gehen neue Parameter, wie das Alter der Domain und die Geschwindigkeit der Website, in die Wertung ein. Während man das Domainalter nicht nachträglich ändern kann, besteht oft Optimierungspotenzial bei der Performance. In seinen Webmaster Tools zeigt Google die gemessene Geschwindigkeit einer Seite an, vergleicht diese mit dem Durchschnitt und gibt Tipps zur Optimierung (siehe Abbildung auf der nächsten Seite).

Googles Webmaster-Tools helfen Website-Betreibern bei der Optimierung der Geschwindigkeit – auch ein Aspket bei der Suchmaschinenoptimierung. So zeigt ein Diagramm beispielsweise an, wie sich die durchschnittliche Ladezeit der eigenen Website in den letzten Monaten verändert hat und ob sie dabei eher zu den schnellen oder langsamen Websites im Google-Index gehört.

Hilfreiche Tools

Mit kostenlosen Werkzeugen wie Firebug [2], YSlow [3] oder Page-Speed [4] kann man eine Website auf Möglichkeiten zur Verbesserung der Geschwindigkeit untersuchen.

Mit TYPO3-Erweiterungen wie „scriptmerger“ lassen sich beispielsweise mehrere CSS und JavaScript-Dateien zusammenfassen, optimieren und mit gzip komprimieren. Dadurch reduziert man sowohl die Zahl der Anfragen, als auch die zu übertragenden Datenmengen deutlich.

Viele Tipps zur Steigerung der Performance bietet die Website von Steve Souders [5]. Sollte die von Google gemessene Geschwindigkeit auch nach Abschluss der Optimierung unbefriedigend sein, kann gegebenenfalls auch ein Wechsel des Providers den gewünschten Effekt liefern.

Sprechende URLs moderat einsetzen

Vor einigen Jahren hatten Suchmaschinen noch Probleme mit dynamischen Parametern in der URL, also den Angaben, die nach einem Fragezeichen kommen. Abhilfe schaffte in TYPO3 die Verwendung der Funktion „simulateStaticDocuments“. Diese simulierte bei allen Links eine statische URL, die beim Aufruf dann wieder in die ursprünglichen Parameter zurückübersetzt wurde. Von Nachteil ist jedoch, dass die Website nach Außen nur eine flache Hierarchie ohne Unterverzeichnisse abbildet und dass dynamische Parameter durch einen verkürzten md5-Hash nicht unbedingt die Lesbarkeit der URLs verbesserten.

Die Extensions „realurl“ und „cooluri“ lösen dieses Problem. Die Hierarchie der Seite wird ähnlich wie beim Navigationspfad (Brotkrumen-Menü) in der URL abgebildet. Suchmaschinen erkennen an URLs wie „/produkte/tv/led“, „/produkte/tv/lcd“ und „/produkte/tv/plasma“ die Struktur der Seite, zudem können Besucher sich die Adressen leichter merken. Für die Umsetzung der URLs werden meist die Seitentitel verwendet, dabei werden Leer- und Sonderzeichen sowie Umlaute entsprechend umgewandelt.

Durch geschickte Wahl der Seitentitel können Seitenbetreiber passende Suchbegriffe in die Adresse einbauen. Allerdings sollte man hier nicht übertreiben: Untersuchungen haben gezeigt, dass die Suchmaschinen nur die ersten sieben bis acht Elemente in der Adresse auswerten. Als Trennzeichen für Elemente gelten Binde-, Unter- und Schrägstriche. Mit URLs wie „/produkte/beschreibung-meines-produkts-mit-vielen-worten/tolle-eigenschaften-guter-preis“ schießt man über das Ziel hinaus. Die URLs einzelner Seiten lassen sich in der realurl-Konfiguration anpassen und ganze Menüebenen bei Bedarf überspringen. Die Konfiguration der realurl-Erweiterung ist zum Teil knifflig, eine detaillierte Anleitung gibt es unter [6].

SEO für Bilder

Auch Bilder kann man für die Indexierung optimieren. Wichtig ist hier ein Eintrag im ALT- und TITLE-Tag mit einer Beschreibung des Bildinhalts. Auch kann man Suchbegriffe in den Dateinamen integrieren. Bei allen Bildern jedoch, die TYPO3 dynamisch erzeugt, wird ein Dateiname in der Form „/typo3temp/pics/a574bf7c1b.jpg“ generiert. Mit Hilfe der Extension „fl_realurl_image“ kann man jedoch auch hier einen sprechenden Pfad bilden. Über Einstellungen in den TypoScript-Konstanten legt man fest, aus dem Inhalt welcher Datenfelder die URL gebildet wird.

Sitemap für Suchmaschinen

Man kann natürlich darauf hoffen, dass die Robotor der Suchmaschinen nach und nach die komplette Struktur der Website erfassen. Seit einigen Jahren gibt es aber die Möglichkeit, selbst aktiv zu werden. Dazu erstellt man eine Sitemap im XML-Format und teilt diese den Suchmaschinen mit. Dadurch kennen diese die komplette Struktur einer Site und können die Robotor gezielt vorbei schicken. Mit Hilfe von TYPO3-Erweiterungen wie „google_sitemap“ hält man diese Listings immer aktuell, neue Seiten werden automatisch aufgenommen. Die Konfiguration einer solchen Sitemap-Extension beschreibt [7].

Passenden Seitentitel festlegen

Nach dem Domainnamen ist der Seitentitel eines der wichtigsten Kriterien für das Ranking bei Suchmaschinen. Hier übernimmt die Suchmaschine den im Browsertitel angezeigten Text und zeigt diesen beim Suchergebnis in blauer Schrift an. TYPO3 verwendet standardmäßig den Seitentitel für den title-Tag. Mit einer Erweiterung wie „browser_page_title“ kann man jedoch den Titel und damit den von der Suchmaschine angezeigten Text individuell festlegen. Sinnvoll ist hier eine Länge von sechs bis acht Wörtern, mehr wird ohnehin nicht angezeigt. In diesem kurzen Text steckt oft ein großes Optimierungspotenzial: es kommt nicht nur darauf an, hier die richtigen Suchbegriffe unterzubringen. Vielmehr muss man die Formulierung so wählen, dass der Suchende den Eintrag auch anklickt.

Formulierungen wie „Willkommen auf unserer Homepage“ sind zwar nett gemeint, aber wenig hilfreich. Auch hier ist Ehrlichkeit wichtig: man sollte nichts versprechen, was die Seite nicht hält. Also nicht „Kostenloser Ratgeber für Thema XYZ“, wenn dieser auf der Seite nicht vorhanden ist oder doch etwas kostet. Da der Browsertitel so wichtig ist, sollte man hier unbedingt genügend Zeit für die richtige Formulierung aufwenden.

Aufgaben der Redakteure

Nur ein Teil der Optimierungen lässt sich mit technischen Lösungen implementieren. Einen wesentlichen Anteil an den Maßnahmen haben die Redakteure. Mittel- und langfristig kommt es vor allen Dingen auf den (guten) Inhalt der Seiten an. Nur Inhalt, der für den Leser interessant ist und einen Nutzen bietet, hat gute Chancen, von den Suchmaschinen als relevant eingestuft zu werden und dauerhaft Verlinkungen von anderen Seiten zu erhalten.

Redakteure müssen daher wissen (oder geschult werden), wie man Texte für Online-Medien schreibt und passende Überschriften findet. Für jede Seite sollte man Suchbegriffe und deren Synonyme festlegen, mit denen die Seite in den Suchergebnissen erscheinen soll. Wichtig ist es dabei, sich in die Rolle des Besuchers zu versetzen, da dieser für ein Produkt vielleicht einen ganz anderen Suchbegriff verwendet. Sonst kann es passieren, dass beispielsweise ein Hersteller von Werkzeugen seine Seite für den sachlich korrekten Begriff Schraubendreher optimiert, potenzielle Kunden jedoch nach dem umgangssprachlich gebräuchlichen Wort Schraubenzieher suchen.

Die festgelegten Suchbegriffe sollte man im Inhalt der Seite streuen und in Fließtext, Überschriften, Linkbeschreibungen (title-Tag) unterbringen. Auch kann es sinnvoll sein, die Begriffe gelegentlich durch Fettschrift (strong-Tag) hervorzuheben.

Worauf man verzichten sollte

Das Ranking in den Suchmaschinen wird auch dadurch bestimmt, welche anderen Seiten auf den eigenen Internetauftritt verlinken. Dabei geht es nicht nur um die Zahl, sondern vor allem die Qualität der Links. Auch wenn die Versuchung groß ist, sollte man von der Verwendung gekaufter Links absehen. Sollte der „Verkäufer“ den Suchmaschinen bekannt sein, kann es sonst genau den gegenteiligen Effekt haben und die eigene Seite abgestraft werden. So wurden in einem bekannt gewordenen Fall die Websites der Kunden einer unrühmlichen Optimierungsfirma aus dem Google Index entfernt.

Fazit

Der Einsatz von SEO-Maßnahmen ist für einen Erfolg einer Website wichtig. Um die Strategien richtig umzusetzen, ist kein großes Budget, jedoch eine Portion gesunder Menschenverstand notwendig. Gute Ergebnisse lassen sich bereits mit kleinen technischen Maßnahmen erzielen, die Rolle eines guten Texters darf man dabei nicht unterschätzen.

Der Autor

Jochen Weiland beschäftigt sich seit Anfang 2002 mit TYPO3. Seine Agentur jweiland.net hat sich auf das Hosting von TYPO3-Projekten spezialisiert und gehört zu den führenden TYPO3-Dienstleistern.

Es ist Montag. In einem Projektteam eines fiktiven Unternehmens arbeitet Jörg als Projektmanager. Jörg hat soeben mit seinem Teamleiter Marc über die Ziel- und Leistungsvereinbarungen des kommenden Geschäftsjahres gesprochen. Zum einen hat das Unternehmen erkannt, dass es von seinen Zweijahres-Releasezyklen weg muss, zum anderen will man sich flexibler am Markt orientieren. Dies sollen alle Team- und Projektleiter umsetzen. Marc hat schon einiges von diesem Scrum gehört und so kommen Marc und Jörg zu der Übereinkunft, dass das Unternehmen zukünftig Scrum einsetzen soll. Jörg ist für die Einführung in seinem Team zuständig. Jörg hat sich bisher nicht mit dem Thema „agiles Projektmanagement“ auseinandersetzen müssen. Er bemüht kurzum eine bekannte Suchmaschine und schon der erste Treffer wirkt durchaus vielversprechend: der ScrumGuide [1]. Jörg notiert sich die wichtigsten Begriffe und Features von Scrum, um sich in das Thema einzuarbeiten.

Scrum im Überblick

Scrum ist eine Methode für die agile Durchführung von Projekten. Dabei beschreibt diese Methode einen interaktiven und inkrementellen Prozess für das Organisieren von Teams und das Entwickeln von Produkten. Scrum soll dabei helfen, Tasks schneller und auch besser zu erledigen. Die Methode setzt auf Eigenmotivation von Teams, die sich aus dem Fakt ergibt, dass Teammitglieder selbst entscheiden, wann und wie sie einzelne Aufgaben ausführen. Während des Scrum-Prozesses setzt das Team Kundenanforderungen durch schrittweise Priorisierung schneller um als bei Projekten, die nicht auf Scrum setzen.

Die Basis des agilen Ansatzes ist demnach die Maßgabe, etwas Schritt für Schritt zu entwickeln. Meist setzt man als erstes auf die wichtigsten Features. Scrum baut auf drei Säulen auf: Transparenz, Inspektion und Adaption. Transparenz soll für die Sichtbarkeit aller Prozessaspekte sorgen, die das Ergebnis beeinflussen. Mit Inspektion ist gemeint, dass alle Prozessaspekte so häufig untersucht werden, dass man inakzeptable Abweichungen entdecken kann. Stellt das Team fest, dass Prozessaspekte abweichen, kommt die dritte Säule von Scrum zum Tragen. Dann gilt es, entweder den Prozess selbst oder die Arbeitsgegenstände zu adaptieren und anzupassen.

So viel zur Theorie. Nun muss Jörg seine Erkenntnisse in die Praxis umsetzen.

Aller Anfang ist schwer

Aber wo fängt man an? So schwer kann das ja eigentlich nicht sein, denkt sich Jörg. Immerhin umfasst der Scrum Guide nur wenige Seiten und die wichtigsten Punkte hat er schließlich auch noch mal selbst zusammengefasst. Flexibilität lautet das Ziel und da passt ja im Grunde der iterative Ansatz von Scrum hervorragend! Allerdings müssen diese ganzen anderen Sachen wie noch mehr Meetings oder neue Rollen von Teammitgliedern ja nun wirklich nicht sein.

In vielen Fällen möchten Unternehmen zwar Scrum einführen, gehen aber davon aus, dass das Lesen eines Buchs ausreicht, um die grundlegenden Gedanken zu verstehen. Doch obwohl die Grundlagen relativ einfach sind, ist die disziplinierte Umsetzung meist schwieriger als gedacht. Man sollte sich zumindest nach anderen agilen Praktikern umsehen, um Gedanken dazu auszutauschen.

Auf in Richtung Ziel

Es sind nun etwa zwei Monate vergangen und Marc erkundigt sich bei Jörg, wie es denn um die Umsetzung von Scrum bestellt ist. Jörg ist nicht ganz glücklich mit der Situation. Die Sprints sind zwar da, aber nicht wirklich greifbar. Jörg zeigt Marc seine Übersicht der Sprints:

Ein Besuch bei der lokalen User Group [2] bringt ein wenig mehr Licht ins Dunkel. Jörg hat eine Gruppe von Praktikern gefunden und tauscht bei einem der Treffen Erfahrungen aus. Jörg scheint mit seinem Problem nicht allein zu sein: Er erfährt, dass die Sprintlängen konsequent auf gleicher Länge gehalten werden sollten, um die einzelnen Sprints untereinander vergleichen zu können. Nur so kann man die Produktivität auch messen.

Auch die Messung des Fortschritts ist bei Jörg anscheinend suboptimal gelaufen. Ein Mitglied der User Group erklärt ihm, dass man den Fortschritt bei Scrum entgegen traditionellem Vorgehen nicht in abgeschlossenen Phasen misst, sondern in der Anzahl produktionsreifer, hochqualitativer, getesteter Funktionen.

Wie Software schrittweise entsteht

Einer der Werte des Agilen Manifests [3] leitet sich aus dem Fakt ab, dass die Offenheit gegenüber Änderungen höher bewertet wird als das strikte Befolgen eines Plans. Doch was bedeutet das konkret? Man geht in Softwareprojekten davon aus, dass das, was zu Anfang des Projekts an Anforderungen da ist, nicht fix ist. Vielmehr wird sich der Leistungsumfang über die Projektlaufzeit verändern und sich den Gegebenheiten anpassen. Aus diesem Grunde muss man die Software beziehungsweise die Entwicklung selbiger so flexibel wie möglich halten.

Aus dem eXtremeProgramming ist YAGNI („You ain't gonna need it“) bekannt. Grob gesagt heißt das, dass man Dinge nur dann entwickeln sollte, wenn klar ist, dass man sie auch tatsächlich braucht. Somit entwickelt sich das Produkt inkrementell und nur im nötigen Rahmen. Daraus ergeben sich Produkte, die schlank sowie leichter wart- und erweiterbar sind. Die Entwickler können sich dadurch auf das Wesentliche konzentrieren und verschwenden ihre Zeit nicht auf Dinge, die vielleicht gar nicht benötigt werden.

Jörg nimmt die Hinweise der anderen erfahrenen Praktiker aus dem Treffen der lokalen User Group mit und setzt die Länge eines Sprints auf zwei Wochen fest. Noch mal im Scrum Guide nachgeschlagen, ergeben für Jörg nun auch die zusätzlichen Meetings einen Sinn:

• Sprint-Planung
• Daily Scrum
• Sprint Review

Wenn Sprints immer die gleiche Länge haben, sind Start- und Endzeitpunkt auch immer gleich. Jörg wurde außerdem noch ein kleines Büchlein mit Praxiserfahrungen [4] genannt, aus dem er die Idee mitgenommen hat, Sprints am Montag zu starten und am Freitag zu beenden. So hat das Team noch ein wenig Erholungspause zwischen den Sprints.

Das Review am Ende eines Sprints ist für Jörg allerdings eher enttäuschend, denn das Team ist meist nicht in der Lage, ihm einen entsprechenden Fortschritt zu präsentieren. Auch die Fortschrittmessung in geleisteten Mannstunden bringt Jörg nicht wirklich voran, da sich die entsprechenden Schätzungen zu sehr ändern und nur schwer vergleichbar sind.

Jörg hat zwar einige Ideen gut aufgenommen und umgesetzt. Bei anderen Dingen besteht allerdings noch viel Verbesserungspotenzial.

Das Geheimnis erfolgreicher Sprints

Wie schon erwähnt, sollten Sprints immer die gleiche Dauer haben, damit diese untereinander vergleichbar werden und somit eine Verbesserung des Teams ersichtlich wird. Man bezeichnet einen Sprint auch als „timeboxed“. Viele Teams scheitern am Timeboxing. Timeboxing ist aber eigentlich nichts anderes, als dass man sich für eine bestimmte Tätigkeit einen festen zeitlichen Rahmen setzt und diesen um nichts in der Welt überzieht. Eher sollte man sich am Ende fragen, ob eine weitere Timebox nötig ist und welche Länge diese dann haben sollte. In Scrum ist im Grunde alles timeboxed (siehe das Kleine Scrum-Lexikon). Timeboxen helfen allen Beteiligten, fokussiert an einem konkreten Thema zu arbeiten.

Ursprünglich war die Idee für das Seitentemplate in TYPO3 genauso einfach wie leistungsunfähig. Man hat ein HTML-Template und platziert dort Marker unter Verwendung eines String, der mit den Zeichen „###“ anfängt und wieder aufhört. Später ersetzt man den Marker dann im TypoScript beispielsweise mit dort generiertem Inhalt. Einen Schritt weiter geht der so genannte Subpart – dieser besteht lediglich aus zwei Markern und der Regel, dass alles innerhalb der Marker enthaltene inklusive der Marker selbst mit dem Inhalt ersetzt wird.

Die Schwächen dieses Vorgehens sind offensichtlich. Da es sich bei dem System lediglich um eine Textersetzung handelt, muss TypoScript den kompletten Inhalt inklusive der kompletten Darstellungslogik erzeugen. Will man nun an der Darstellung etwas ändern, kommt man nicht umhin, direkt in das TypoScript einzusteigen und dort die Änderungen vorzunehmen. Ebenso kann das Ganze in einer Arie aus Conditions und Extension-Templates ausarten, wenn man beispielsweise bei jedem Template verschiedenste Untertemplates einbinden will – oder man verwendet dafür spezialisierte Extensions. Wie man es aber dreht und wendet – es ist und bleibt suboptimal.

<!-- ###DOCUMENT begin -->
<div id =“content“>
###CONTENT###
</div>
<!-- ###DOCUMENT end -->

page = PAGE
page.10 = TEMPLATE
page.10 {
	template = FILE
	template.file = fileadmin/site/template/tpl_main.html
	workOnSubpart = DOCUMENT
	marks {
		CONTENT < styles.content.get

Die neue TYPO3 Version 4.5 soll diesen Umstand zumindest dahingehend aufheben, als dass es nun möglich ist, die neue und bislang nur für FLOW3 beziehungsweise für Extbase verwendete Templating-Engine Fluid auch für das Seitentemplating zu benutzen. Dies realisiert das neu eingeführte TypoScript-Objekt „FLUIDTEMPLATE“, das im Hintergrund den ebenfalls in TYPO3 4.5 neu eingeführten Fluid-Standaloneview verwendet.

Installation und Konfiguration

Um das neue TypoScript-Objekt verwenden zu können, muss man sicherstellen, dass Fluid (Extension-Key: fluid) und Extbase (Extension-Key: extbase) im System installiert sind. Dies kann man ganz einfach im Extension-Manager überprüfen.

Im nächsten Schritt kopiert man das bisherige Template und verwendet dort statt des Markers die Zeichenkette {content}. Nun kann TypoScript diese ansprechen:

<div id =“content“>
{content}
</div>

page = PAGE
page.10 = FLUIDTEMPLATE
page.10 {
	template = FILE
	template.file = fileadmin/site/template/tpl_fluid_main.html
	variables {
		content < styles.content.get

Bislang erinnert das Handling an das bekannte Vorgehen, aber es hat sich bereits einiges im Hintergrund getan – unter anderem hat das System die Daten anders transportiert. So gibt es nicht etwa die Content-Elemente der Spalte „Normal“ aus, sondern deren Datenbankinhalt – also ohne die zugehörige HTML-Darstellung. Dies liegt schlicht daran, dass normalerweise die TypoScript-Bibliothek „css_styled_content“ für die Darstellung verantwortlich ist – bei Fluid kann der Nutzer aber selbst im View entscheiden, wie dieser dargestellt werden soll – daher kann der Anwender die Darstellung als HTML explizit anstoßen. Um dies zu realisieren, schreibt man folgendes in das Template:

<div id =“content“>
<f:format.html>{content}</f:format.html>
</div>

Wer sich bereits mit Fluid beschäftigt hat, sieht sofort, dass hier ein sogenannter Fluid-ViewHelper zum Tragen kommt – eine eigene Klasse innerhalb der Fluid-Systemextension, die in diesem Fall für die Formatierung der Ausgabe in HTML zuständig ist.

Zugriff auf die Seiteneigenschaften

Das Array „data“ übergibt alle Seiteneigenschaften (wie UID, Titel, Navigationstitel) automatisch an den Fluid-View. Die Seiteneigenschaften stehen dementsprechend dort zur Verfügung.

Dafür verantwortlich ist letztlich die Anweisung „$view->assign('data', $this->cObj->data);“ in der Datei „typo3/sysext/cms/tslib/content/class.tslib_content_fluidtemplate.php“.

Man kann jede der Eigenschaften ganz einfach auslesen, indem man die Eigenschaft als „Schlüssel“ für das Array „data“ verwendet und darauf mit der Punktsyntax von Fluid zugreift:

Sie befinden sich auf der Seite mit der UID {data.uid} und dem Titel {data.title}
<f:if condition="{data.layout}==1">
<f:then>
Layout-Feld steht auf dem Wert "Layout 1"
</f:then>
<f:else>
Layout-Feld steht NICHT auf dem Wert "Layout 1"
</f:else>
</f:if>
Alle Eigenschaften: <f:debug>{data}</f:debug>

Das Beispiel zeigt auch, wie man im Template das Layout-Feld der Seiteneigenschaften mit dem If-ViewHelper abfragen kann, um daraufhin eine andere Ausgabe zu erzeugen. Dies funktioniert natürlich auch mit allen anderen Feldern.

Eine Übersicht über alle verfügbaren Eigenschaften bietet der Fluid Debug-ViewHelper – diesen zeigt das oben stehende Listing ebenfalls am Ende. So kann man einerseits die zur Verfügung stehenden Schlüssel wie auch deren aktuelle Werte nachsehen.

TypoScript everywhere

Ein Nachteil der bisherigen Marker-Methode besteht darin, dass man im Abschnitt, der die Marker befüllt, festlegen muss, welche TypoScript-Ausgabe man im Template verwenden will. Das bisherige Vorgehen beinhaltete die Integration eines Markers in das Template und die Zuweisung des TypoScript-Objekts an den Marker. Dies ist nicht nur sehr unflexibel, sondern auch fehleranfällig.

Alternativ kann man nun ein FLUIDTEMPLATE verwenden. Schließlich gibt es einen CObject-ViewHelper, der beliebige TypoScript-Objekte direkt ohne vorherige Zuweisung flexibel integriert, in dem man lediglich den TypoScript-Pfad angibt, der irgendwo im TypoScript-Setup definiert sein muss.

Das folgende Beispiel zeigt jeweils, wie die TypoScript-Objekte aufgebaut sind und darunter den jeweiligen Code, um darauf im Template zuzugreifen.

lib.test1 = TEXT
lib.test1.value = Aus dem TypoScript!

lib.test2 = IMAGE
lib.test2 {
	file = GIFBUILDER
	file {
		XY = 300,30
		backColor = #cc0000
		10 = TEXT
		10.text.current = 1
		10.fontColor = #ffffff
		10.offset = 10, 25
	}
}

<f:cObject typoscriptObjectPath="lib.test1" />
<f:cObject typoscriptObjectPath="lib.test2">Das wird als Bild gerendert</f:cObject>

Über das Attribut „typoscriptObjectPath“ des „cObject“-ViewHelpers kann man so beispielsweise das TypoScript-Objekt „lib.test1“ adressieren und somit direkt an dieser Stelle ausgeben – ohne es vorher explizit zuzuweisen.

Diese Methode funktioniert aber nicht nur vom TypoScript-Setup ins Template, sondern auch umgekehrt. So kann man Werte aus dem Template an eine TypoScript-Bibliothek übergeben und das Ergebnis wiederum im Template anzeigen lassen. So rendert das zweite Beispiel den String innerhalb des ViewHelpers durch das TypoScript-Objekt „lib.test2“ mit dem GIFBUILDER und zeigt wiederum das Bild im Template an.

Entscheidend ist hier, dass die „Eingabe“ innerhalb des ViewHelpers an das TypoScript-Objekt so übergeben wurde, dass man dort mittels der stdWrap-Eigenschaft „current = 1“ darauf zugreifen kann. Das macht man sich zunutze, indem man bei der GIFBUILDER-Eigenschaft „text“ darauf zugreift.

Layout und Partials

Gerade bei umfangreichen Darstellungen stellt man fest, dass die Ausgabe drei wiederkehrende Bestandteile hat:

• Ein Layout, das beispielsweise CI-Elemente oder eine Bereichsnavigation enthält
• Das Template, das die klassische Ausgabe enthält
• Immer wiederkehrende Teile (Partials), die man nur einmal definiert und an vielen Stellen einbinden kann. Sobald ein bestimmter Abschnitt im Template öfter als einmal unverändert auftaucht, kann man diesen in einem Partial auslagern

Im nächsten Schritt legt man im Verzeichnis „fileadmin“ die beiden Verzeichnisse „Layouts“ und „Partials“ an und konfiguriert den jeweiligen Pfad mit Hilfe von TypoScript (siehe nächster Abschnitt):

page.10 = FLUIDTEMPLATE
page.10 {
	layoutRootPath = fileadmin/Layouts/
	partialRootPath = fileadmin/Partials/
}.

Nun kann man beides im Template verwenden:

<f:layout name="defaultLayout" />
<f:section name="content">
<h2>It works :-)</h2>
<f:render partial="testpartial" />
Weiterer Text...
</f:section>

<h1>Das kommt aus dem Layout</h1>
<f:render section="content" />

Die Ausgabe, besonders bei umfangreichen Darstellungen, beinhaltet mit dem Layout, dem Template für die Ausgabe und den Partials (einmal definierte und wiederkehrende Teile) drei wiederkehrende Bestandteile.

Beim Aufbau der Layout-Template-Struktur muss man nun etwas um die Ecke denken:

1. Das Template selbst wird über die file-Eigenschaft des FUIDTEMPLATE Content-Objekts definiert und aufgerufen.
2. Dieses Template-File kann einen Layout-ViewHelper beinhalten (oben in der ersten Zeile). Dieser bestimmt wiederum das Layout-Template-File. An diesen unter dem Attribut „name“ angegebenen Namen wird „.html“ zugefügt (beziehungsweise die entsprechende zuvor mit der TypoScript-Eigenschaft „format“ festgelegte Formatendung) und das File aus dem ebenfalls per TypoScript konfigurierten Verzeichnis.
3. Im Layout-Template-File kann man das Layout definieren. An der Stelle, an der man das Template platzieren will, verwendet man den ViewHelper <f:render section="content" />. Als Attribut „section“ benutzt man genau den Namen, den man im Haupt-Template über den Section-ViewHelper <f:section name="content"> verwendet hat. Damit wird dann der Abschnitt (Section) des Templates gerendert.
4. Partials kann man beliebig platzieren, indem man den Render-ViewHelper <f:render partial="testpartial" /> verwendet. Hier gilt ebenfalls, dass Fluid im jeweiligen konfigurierten Verzeichnis nach dem Partial sucht, das den angegebenen Namen inklusive der Dateiendung, die per Default .html lautet, haben muss.

TypoScript-Optionen

Zusammenfassend finden Sie in nachfolgender Tabelle alle TypoScript-Optionen, die mit dem Content-Objekt FLUIDTEMPLATE möglich sind.

Auf "file", "layoutRootPath" und "partialRootPath" können zudem stdWrap Eigenschaften angewendet werden.

Fazit

Das TypoScript-Content-Objekt ist bereits jetzt extrem leistungsfähig und unterstützt TYPO3-Entwickler in vielerlei Hinsicht optimal. Zudem stehen so Funktionen zur Verfügung, die mit der klassischen Methode schlicht nicht möglich sind. Man denke beispielsweise alleine an die ViewHelper. Darüber hinaus existieren eigene ViewHelper, die mit wenig Aufwand die Möglichkeiten des Templating erheblich erweitern.

Allerdings fallen einem schnell Dinge auf, die nicht beziehungsweise noch nicht realisiert wurden. So ist es durchaus sinnvoll, dass beispielsweise das Auslesen einer Backend-Spalte nicht alle dort vorhandenen Inhaltselemente als einen String zurückliefern sollte, sondern als Array. Dann könnte man darauf auch andere Viewhelper wie „Cylcle“ oder „For“ anwenden, um so jedes Content-Element einzeln anzusprechen.

Ebenfalls möglich wäre dann vielleicht ein Zugriff auf einzelne Eigenschaften eines Content-Elements. Einem Kommentar im Bugtracker zufolge ist dies für Version 4.6 angedacht.

Der Autor

Patrick Lobacher ist Inhaber und Geschäftsführer der Full-Service Agentur "typovision – Agentur für multimediale Kommunikation" (www.typovision.de), Autor, Trainer, Programmierer, Silber-Mitglied der TYPO3 Association und „Certified TYPO3 Integrator“ und nicht zuletzt ein Digital Native. Er berät seit 1996 Unternehmen beim Einsatz von Webtechnologien, insbesondere seit 2002 zunehmend im TYPO3-Umfeld.