Erstellt man mittels mysqldump ein Backup der Datenbank, verwendet man wohl so was ähnliches, wie folgt:

mysqldump -h HOST -u USER DBNAME -p > FILENAME.sql

Als Ergebnis erhält man ein MySQL-Skript, mit welchem man mittels mysql die komplette Datenbank wieder herstellen kann und zwar wie folgt:

mysql -h HOST -u USER DBNAME -p < FILENAME.sql

Import zerlegt

So weit - so gut. Das dürfte für die Meisten nichts Neues sein. Handelt es sich nun jedoch bei FILENAME.sql um einen recht großen Dump, muss man diesen eventuell mit split zerlegen. Das könnte man zum Beispiel mit einem der folgenden Anweisungen erledigen:

#Erzeugt Dateien mit jeweils 1000 Zeilen Länge
split -l 1000 FILENAME.sql
#Erzeugt Dateien mit jeweils 1 MB Größe
split -b 1M FILENAME.sql

Import nach Maß

Um nun nur eine bestimmte Tabelle des Dumps zu importieren, macht man sich die Struktur des dump-Files zu eigen. Dieses liegt in der folgenden wiederkehrenden Form vor:

• Tabellenkommentar
• CREATE TABLE - Anweisung
• Zeilenkommentar
• INSERT - Anweisungen

Jeder Tabellenkommentar sieht wie folgt aus:

--
-- Table structure for table `TABELLENNAME`
--

Nun kann man sich von grep die Zeilennummern ausgeben lassen, in denen "Table structure for table" steht:

grep -n 'Table structure for table' FILENAME.sql
# Ergibt folgende Ausgabe:
# 19:-- Table structure for table `table1`
# 44:-- Table structure for table `table2`
# 447:-- Table structure for table `table3`
# 544:-- Table structure for table `table4`
# 625:-- Table structure for table `table5`

Die letzte Zeile einer Tabellensequenz, heißt bei mir immer "UNLOCK TABLES;". Somit können wir die Länge der letzten Tabelle bestimmen:

grep -n 'UNLOCK TABLES;' FILENAME.sql
# Ergibt folgende Ausgabe:
# 41:UNLOCK TABLES;
# 444:UNLOCK TABLES;
# 541:UNLOCK TABLES;
# 622:UNLOCK TABLES;
# 674:UNLOCK TABLES;

Die Nummer der letzten Zeile bekommt man mit:

grep -n 'Dump completed' FILENAME.sql
# Ergibt folgende Ausgabe:
# 686:Dump completed

Möchte man nur bestimmte Zeilennummern des Dumps importieren, kann man diesen mit sed erstellen:

#Erzeugt eine Datei mit den Zeilen 43 bis 445 des Dumps (table3):
sed -n '43,445 p' < FILENAME.sql > FILENAME_part.sql

Zu beachten gilt:
Am Anfang der FILENAME.sql befinden sich Anweisungen, die die Datenbankverbindung für den Import konfigurieren. Unter Anderem wird hier die Zeichenkodierung der Verbindung gesetzt. Am Ende des Datenbankskriptes (nach der letzten Tabellensequenz) werden diese Parameter wieder zurückgesetzt.

Im Folgenden wollen wir sowohl den Header als auch den Footer an den Tabellendump kleben:

# Header extrahieren:
sed -n '1,17 p' < FILENAME.sql > header.sql
# Tabelle (table3) extrahieren:
sed -n '43,445 p' < FILENAME.sql > FILENAME_part.sql
# Footer extrahieren:
sed -n '675,686 p' < FILENAME.sql > footer.sql
# Zusammenführen der Dateien:
cat header.sql FILENAME_part.sql footer.sql > table3.sql
# Import:
mysql -h HOST -u USER DBNAME -p < table3.sql

Meine Systemvoraussetzungen:

• MacOSX 10.6.4
• PDT 1.2
• XAMPP für Mac OSX

Um PHPUnit zu installieren, wird das PEAR-Framework vorausgesetzt. Um zu testen, ob dieses installiert ist, kann man dieser Anleitung folgen. Wer, wie ich Xampp unter Mac OSX einsetzt, findet die pear-Binary normalerweise unter:

.

Um nun PHPUnit zu installieren, geben wir folgende Befehle ein:

cd /Applications/xampp/xamppfiles/bin
sudo ./pear channel-discover pear.phpunit.de
sudo ./pear channel-discover pear.symfony-project.com
sudo ./pear install phpunit/PHPUnit

Nun sollte PHPUnit installiert sein, was wir mit folgender Anweisung testen können:

cd /Applications/xampp/xamppfiles/bin
sudo ./phpunit --version

Um nun PHPUnit in PDT zu integrieren, installieren wir uns das Eclipse-Plugin “PHP Tool Integration (PTI)” von PHPsrc.
Zur Installation des Plugins:

1. PDT > Help > Install New Software …
2. Add > http://www.phpsrc.org/eclipse/pti/
3. Dann bei den gewünschten Paketen einen Haken rein und ab dafür.

Die letzte Hürde, die wir zu nehmen haben, ist nach dem Neustart von PDT die Konfiguration vom PTI-Plugin.
Hierzu gehen wir wie folgt vor:

1. Eclipse > Einstellungen > PHP > PHP Executables > Add…
   • Name: PHP
   • Executable Path: /Applications/xampp/xamppfiles/bin/php
   • PHP ini file (optional): /Applications/XAMPP/xamppfiles/etc/php.ini
   • SAPI Type: CLI
   • PHP Debugger: XDebug
2. Eclipse > Einstellungen > PHP Tools > PHPUnit > PHP Executables > “PHP”

Fertig!

Nun stehen einem die Funktionen des PTI-Plugins zur Verfügung, womit sich der Entwicklungsprozess von PHP-Anwendungen noch effektiver gestalten lässt.
Wer zum Beispiel einen Continous Integration Server, wie PHPUnderControl einsetzt, kann mit diesem Plugin, die auf dem CI-Server ausgeführten Tests & Checks (PHPUnit, PHP_CodeSniffer, PHPcpd, PHP Depend) schon einmal lokal prüfen, um die Anzahl der fehlgeschlagenen Builds möglichst gering zu halten.
Verantwortliche Codezeilen für fehlgeschlagene Tests & Checks werden direkt im Code hervorgehoben.

org.jvnet.substance.api.UiThreadingViolationException: Component creation must be done on Event Dispatch Thread

Zugegeben: Es war schon etwas waghalsig zu glauben, dass dies auch einfach so mal gehen kann. Aber Hallo? Man darf ja wohl noch träumen.

Die Lösung auf das Problem findet man in folgendem Beitrag und ist gleichermaßen simpel und erschreckend: Substance 5.0 and Event Dispatch Thread.

Die Quintessenz ist folgende: In meiner konkreten Anwendung ist die Initialisierung der GUI in der start-Methode eines Singleton-Application-Objektes eingepackt. Im Konstruktor findet die Einbindung des Substance-Look-and-Feels statt. Im Prinzip also beinahe dieselben Voraussetzungen, wie im oben verlinkten Beispiel des französischen Kollegen. Um die Exception zu vermeiden, muss der Aufruf des GUI-Konstruktors – wie übrigens auch in jedem Swing-Tutorial der Welt beschrieben – in einer Instanz eines neuen Event Dispatch Threads erfolgen.

Und so sieht das dann aus:

public static void main(String[] args) {
    java.awt.EventQueue.invokeLater(new Runnable() {
	public void run() {
	    Application application = Application.getInstance();
            application.start();
	}
    });
}

Die Klasse

sieht in gekürzter Version dann, wie folgt aus:

// implementiert das Singleton-Pattern
public class Application {
    // Die einzige Instanz der Klasse Application
    private static Application application = null;

    private Application() {
        JFrame.setDefaultLookAndFeelDecorated(true);
        try {
            UIManager.setLookAndFeel(new SubstanceBusinessBlackSteelLookAndFeel());
        } catch (UnsupportedLookAndFeelException e) {
            System.err.println(e.toString());
        }
    }

    public void start() {
        // Die Klasse UserInterface erbt von JFrame und erzeugt die GUI
        this.ui = new UserInterface();
    }

    public static synchronized Application getInstance() {
        if(this.application == null) {
            this.application = new Application();
        }
        return this.application;
    }
}

Fazit: Wer auf dieses Problem stößt (so wie auch der, der es beschreibt) hat wohl die erste Stunde der Swing-Lektionen übersprungen. Der Fehler resultiert einzig und allein aus persönlicher Schlamperei und Faulheit. Was man nun – mal wieder – daraus lernt? RTFM

AppName: apache.exe  AppVer: 2.2.11.0  ModName: php_pdo_mysql.dll

Kurzes Googeln brachte die Lösung, dass sich die aktuelle Windows-Version des Xampp-Projektes nicht mit der Nutzung der PDO-Erweiterung verträgt. Eine Problemlösung (zumindest für Windows XP, SP3) findet sich in folgendem Forenbeitrag:

Xampp 1.7: Probelem mit PDO MySQL auf appachefriends.org

Ersetzen der libmysql.dll in den folgenden Verzeichnissen:

\xampp\apache\bin

und

\xampp\php

Downloaden kann man diese Bibliothek mit einem aktuellen PHP-Paket:
http://windows.php.net/downloads/snaps/php-5.2-win32-VC6-x86-latest.zip

Bei mir hat es wunderbar funktioniert. Probleme kann es in Folge dessen jedoch bei anderen Datenbankadaptern geben (mysqli).

UPDATE: Ein Upgrade des Xampp auf Version 1.7.1 behebt die Problematik.

Neben der Erstellung von desktop-ähnlichen GUI’s bietet es ein mächtiges SDK, das dem Entwickler das automatisierte Komprimieren des Quellcodes, Unit-Testing, sowie Erstellen einer API ermöglicht. Ein Überblick über die verschiedenen GUI-Komponenten bietet die Live-Demo: Demo-Browser.

Im Folgenden möchte ich gerne einen kurzen Einstieg in das Framework schildern.

Für ein ausführliches Tutorial ist momentan leider keine Zeit. Eventuell wird eines folgen, wenn das Projekt in der endgültigen Version 1 verfügbar ist. Etwas ausführlichere Tutorials gibt es sowohl englisch- als auch deutschsprachig.

Installation der SDK

Im Vergleich zu anderen AJAX-Frameworks, wie Prototype und JQuery verfolgt es einen für mich neuen Ansatz in der Entwicklung einer Weboberfläche mit JavaScript. Bisher war ich es gewohnt ein, zwei JS-Dateien im Header des XHTML-Dokumentes einzubinden, um direkt im Anschluss in der gewohnten Entwicklungsumgebung meine Skripte zu erstellen.
Das Arbeiten mit Qooxdoo sieht standardmäßig einen Entwicklungsprozess mit dem mitgelieferten, in Phyton geschriebenen, SDK vor. Hierfür muss zunächst Phyton installiert werden, was unter Windows relativ einfach mit ActivePhyton zu realisieren ist.
Für andere Plattformen sind weitere Empfehlungen auf der Herstellerseite zu finden. Dort findet man auch die aktuelle Version des Frameworks. Hat man sich die aktuelle SDK heruntergeladen, wird diese entpackt (c:\qooxdoo).

Hallo Welt!

Um ein neues Projekt mit der Bezeichnung “helloworld” (Achtung: Ein Bindestrich im Projektnamen erzeugt einen Fehler zur Laufzeit!) aufzusetzen, öffnen wir die Konsole und geben folgenden Aufruf ein:

C:\qooxdoo\tool\bin\create-application.py --name=helloworld --out=C:\xampp\htdocs\

Dadurch wird durch das SDK ein Projektverzeichnis mit dem Namen “helloworld” im htdocs-Verzeichnis meiner Xampp-Installation erstellt. Das mache ich, da ich die später noch zu erzeugende API über meinen lokalen Webserver verfügbar haben möchte.

Durch das SDK werden in dem Verzeichnis für das Projekt relevante Konfigurationsdateien, sowie eine kleine Hello-World-Anwendung generiert.
Diese beinhaltet einen Button, der durch Drücken ein

auslöst. Der zugehörige Code befindet sich im Verzeichnis

.

Das obligatorische Hello-World wird also von den Entwicklern bereits mitgeliefert. Um nun trotzdem das Gefühl zu bekommen, etwas geschafft zu haben, werden wir den Button mit einem Tooltip versehen. Hierzu erweitern wir die bereits bestehende “Application.js” um folgende Codezeilen:

var tooltip = new qx.ui.tooltip.ToolTip("Tipp: Durch Drücken des Buttons wird ihnen die"
                                                   +" Hello-World-Ausgabe angezeigt!");
tooltip.setShowTimeout(50);
button1.setToolTip(tooltip);

Das Testen der Anwendung erfordert ein vorheriges Kompilieren der Anwendung. Um die Anwendung zu übersetzen wird folgender Aufruf in die Konsole eingegeben:

cd xampp\htdocs\helloworld
generate.py source

Die Anwendung lässt sich dann im Browser mittels der URL

testen.

Deployment und Dokumentation

Um die Anwendung zu auszuliefern, bietet es sich an den Sourcecode vorher zu bauen. Dazu werden die benötigten Dependencies in eine Datei gepackt und komprimiert. Der Aufruf lautet, wie folgt:

generate.py build

Alle benötigten Dateien befinden sich anschließend im Verzeichnis

und können nun auf den Webserver kopiert werden.

Die projektspezifische API wird durch folgenden Aufruf erzeugt:

generate.py api

Die API ist dann anschließend über folgende URL verfügbar:

.

Fazit

Ziel des Frameworks ist die Unterstützung von RIA’s mittels JavaScript ohne tiefgehende Kenntnisse von HTML, CSS und des DOMs. Ob das bis ins Detail tatsächlich der Realität entspricht, kann ich zum jetzigen Zeitpunkt noch nicht sagen. Was ich sagen kann ist:

Das Framework bzw. das SDK ist nach einer kurzen Einarbeitungszeit leicht zu handhaben und sehr gut dokumentiert. Des Weiteren lassen sich sehr schöne GUI’s entwickeln mit einer Methodik, die stark an die Java-Welt (Swing, SWT) angelehnt ist. Auch die Aufrufe innerhalb des SDK ‘s erinnern an Java-Tools (Ant, Maven).
Die integrierte Möglichkeit zur Durchführung von Unit-Tests erlaubt das Skalieren eines JS-Projektes und somit die Entwicklung von “echten” RIA’s. Das Generieren einer API rundet die ganze Sache ab.

Des Weiteren lässt sich durch den RIA-Ansatz ein sehr schönes MVC umsetzen. Das heißt, dass der Gedanke an eine Kombination eines MVC-Server-Frameworks, wie zum Beispiel dem Zend Framework, und dem hier vorliegenden in meinen Augen durchaus lohnenswert ist. Für mein nächstes Projekt wird dieses Gedankenspiel in jedem Fall eine Rolle spielen. Genaueres werde ich berichten, wenn es so weit ist

Live-Link zum Beispiel: Hallo Welt!
Sourcen: qooxdoo_helloworld_source.zip

Rock im Park / Rock am Ring

Ort: Nürnberg / Nürburgring
Datum: 5. bis 7. Juni
Preis: 135 € inkl. Parken und Campen (bis 15.03.)

Billy Talent · Bloc Party · Bring Me The Horizon · Dragonforce · Dredg · Enter Shikari · Flogging Molly · Gallows · Jan Delay & Disko No. 1 · Juliette Lewis · Kettcar · Kilians · Killswitch Engage · Korn · Limp Bizkit · Mando Diao · Marilyn Manson · Middle Class Rut · Peter, Björn & John · Peter Fox · Placebo · Polarkreis 18 · Scouting For Girls · Selig · The Gaslight Anthem · Slipknot · The Killers · The Kooks · The Prodigy · The Script · The Subways · Tomte · Trivium · Volbeat

Hurricane / Southside

Ort: Scheeßel / Neuhausen ob Eck
Datum: 19. bis 21. Juni
Preis: 115 € inkl. Parken und Campen

Die Ärzte · Ben Harper and Relentless7 · Blood Red Shoes · Clueso · Culcha Candela · Dendemann · Disturbed · Editors · Eskimo Joe · Fettes Brot · Franz Ferdinand · Get Well Soon · Gogol Bordello · Johnossi · Karamelo Santo · Katy Perry · Kings Of Leon · Kraftwerk · Moby · The Gaslight Anthem · The Sounds · The Whip · The Wombats · Tomte

Roskilde Festival

Ort: Roskilde, Dänemark
Datum: (28. Juni), 2. Juli bis 5. Juli
Preis: ab 246 € inkl. Parken und Campen

Coldplay · Madness · Slipknot

Sziget-Festival

Ort: Donauinsel “Óbudai Sziget” in Budapest, Ungarn
Datum: 12. bis 17. August
Preis: 150 € inkl. Parken und Campen

Line-Up noch nicht bekanntgegeben. Momentan läuft noch die Wunschmaschine, bei der man sich 10 Bands für das diesjährige Festival wünschen darf. Fast so schön wie Weihnachten. Wenn meine Wahl angenommen wird wäre das Line-Up also folgendes:

AC/DC · Billy Talent · Franz Ferdinand · Gogol Bordello · Kaiser Chiefs · Mando Diao · Mattafix · Perkalaba · Red Hot Chilli Peppers · The Hives
(ja gut etwas übertrieben, aber wir sind hier ja bei Wünsch-Dir-Was)

Line-Up der letzten Jahre: 2008 2007

FM4 FREQUENCY Festival

Ort: Salzburgring, Österreich
Datum: 20. bis 22. August
Preis: 95 € inkl. Parken & Campen

Auch hier steht noch kein Line-Up fest. Das dürfte sich jedoch in den nächsten Wochen ändern.
Line-Up der letzten Jahre: 2008 2007

… und zum Schluss:

Ich werde diese Zusammenstellung natürlich ständig aktualisieren, sobald sich etwas neues ergibt. Immer mal wieder reinschauen lohnt sich also
Wer Anregungen zu Festivals hat, die musikalisch in meine Ecke passen (siehe Wunsch-Line-Up beim Sziget), darf gerne einen Kommentar dazu hinterlassen.

Alle Angaben ohne Gewähr. Insbesondere Preisangaben können abweichen. Stand: 10.02.2009

In diesem Teil wollen wir uns anschauen, wie aus einer Anfrage über verschiedene URL’s bestimmte Controller aufgerufen werden. Daran sind diverse Elemente beteiligt, die wir zum Teil auch schon im ersten Teil des Tutorials benutzt bzw. kennengelernt haben. Auf Grundlagen, wie die Arbeitsweise eines Webservers (HTTP, mod_rewrite) oder die MVC-Architektur werde ich hier nicht eingehen, da diese Themen an genügend anderen Stellen bereits ausführlichst behandelt werden. Zu den im Folgenden behandelten Komponenten des Zend Frameworks zählen: Front-Controller, Request-Objekt, Router, Dispatcher und der Action-Controller.

Der Front-Controller

Durch die erstellten Dateien im ersten Teil des Tutorials haben wir den Webserver derart konfiguriert, dass alle Anfragen, die nicht auf statische Dateien verweisen, von der index.php entgegengenommen werden. Dies stellt eine Realisierung des Frontcontroller-Patterns dar, welche im Falle des Zend Frameworks von der Klasse Zend_Controller_Front übernommen wird. Des Weiteren gilt zu beachten, dass die Klasse als Singleton implementiert ist. Das bedeutet, dass es nur eine einzige Instanz dieser Klasse gibt, die über eine statische Methode referenziert werden kann:

$frontController = Zend_Controller_Front::getInstance();

Danach kann der Front-Controller konfiguriert werden. Dies betrifft zumindest das Setzen eines Pfades zu einem Verzeichnis, das Action-Controller enthält. Da der Front-Controller als Registry eingesetzt wird, kann man zudem bestimmte Objekte und Umgebungsvariablen an diesen übergeben und später wieder abrufen. Wegen seiner Singleton-Eigenschaft sind diese Daten überall in der Anwendung verfügbar.
Folgende, weitere Aufgaben werden vom Front-Controller übernommen:

• Entgegennehmen der Anfrage
• Einbinden von Plugins mit Hilfe eines Plugin-Brokers (ErrorHandler, ViewRenderer)
• Weiterleiten des Request-Objekts an einen Router und einen Dispatcher

Das Request-Objekt

Dieses Objekt der Klasse

wird defaultmäßig vom Front-Controller instanziiert und beinhaltet zum einen, wie der Name schon vermuten lässt, die Daten aus dem HTTP-Request (Header-Daten GET/POST-Parameter, Art des Requests, etc.). Des Weiteren enthält das Objekt Informationen, die in der Transformationskette generiert werden, in der es sich befindet:

• Name des Moduls
• Name des Controllers
• Name der Action
• Weitere Parameter

Diese Werte werden nach und nach von den einzelnen “Beteiligten” der Transformationskette (Front-Controller, Router, Dispatcher, Action-Controller) gesetzt bzw. abgefragt. Das Request-Objekt kann auch manuell erstellt werden und während des Bootstrappings dem Front-Controller übergeben werden. Dies ist ratsam, wenn man HTTP-Requests im Vorfeld bearbeiten möchte oder andere Protokolle (CLI, PHP-GTK) einsetzen möchte. In diesen Fällen erweitert man die Basisklasse (Zend_Controller_Request_Abstract) und übergibt ein entsprechendes Objekt an die

-Methode. In unserem Kontext (Webanwendung) wird dies jedoch nicht benötigt werden.

Das Routing

Mit Routing ist das Extrahieren der aufzurufenden Action an einem bestimmten Action-Controller und der Identifizierung weiterer Parameter gemeint. Übernommen wird diese Aufgabe im Default-Fall vom Standardrouter der Klasse

. Dieser setzt ein URL-Rewriting voraus und enthält einen Satz von Regeln, die festlegen, wie die gewünschten Informationen aus einer URL extrahiert werden sollen. Beides wurde bereits im vorangehenden Teil des Tutorials beschrieben. Die Standardrouten können natürlich ergänzt werden. Hierzu stehen dem Entwickler vier Klassen von Routen zur Verfügung:

• Zend_Controller_Router_Route
• Zend_Controller_Router_Route_Static
• Zend_Controller_Router_Route_Regex
• Zend_Controller_Router_Route_Hostname

Die erste Klasse dient dazu das Standardrouting dahingehend zu erweitern, dass für einen bestimmten Wert, welcher den zu benutzenden Controller entsprechen würde, festgelegt wird, dass der zweite angegebene Wert nicht auf die Action des Controllers verweist, sondern als Parameterübergabe aufgefasst wird.
Beispiel: Für die URL

soll nicht die Action “autoAction” im Controller “searchController” aufgerufen werden, sondern lediglich nach der Phrase “auto” gesucht werden. Hierzu erweitert man den Regelsatz des Routers, um eine entsprechende Route, mittels folgender Anweisung:

$newRoute = new Zend_Controller_Router_Route('search/:phrase',
    array('controller' => 'search', 'action' => 'index'));
$router->addRoute('search', $newRoute);

Hier wird also durch den Doppelpunkt festgelegt, dass es sich bei dem Wert “auto”, um einen Parameter des Typs “phrase” handelt und am “searchController” die Methode “indexAction” aufgerufen werden soll. Der Parameter “phrase” wird, wie die anderen Werte (Modul-, Controller- und Actionname) auch, im Request-Objekt gespeichert und ist über dieses dann im Action-Controller verfügbar:

// Aufruf im searchController
$request = $this->getRequest();
$phrase = $request->getParam('phrase');

Die anderen Router-Klassen werden ähnlich verwendet. Eine ausführliche Darstellung mit Beispielen findet sich im Programming-Guide des Herstellers.

Der Dispatcher

Der Standard-Dispatcher

übernimmt anschließend den Part, die vom Router festgestellten Werte für Modul, Controller und Action aus dem Request-Objekt auszulesen und die entsprechende Methode aufzurufen. Fehlende Werte werden durch defaults aufgefüllt. Diese Default-Werte können mittels entsprechenden Setter-Methoden gesetzt werden. Ansonsten sind die Default-Werte wie folgt gesetzt:

• ‘default’ für Modul
• ‘index’ für Controller
• ‘index’ für Action

Der Dispatcher sitzt am Ende der Transformationskette des Request-Objekts bevor es an den jeweiligen Action-Controller weitergegeben wird. Mittels der Methode

kann diese Transformationskette aus dem Action-Controller heraus erneut angestoßen werden.

Der Action-Controller

Die Aufgaben des Action-Controllers sind im Prinzip erst einmal unklar. Es ist allein eine Designfrage, welche Aufgabe man ihm zuspricht. Ich habe erst letztens gelesen, dass man ihm eigentlich so wenig wie möglich Logik zuweisen und die Businesslogik in das Modell verlegen soll. Der Vorteil, der bei sogenannten “Fat Models” entstehe, liege in der höheren Modularisierungs- und der damit verbundenen Re-Use-Fähigkeit. Die Aufgaben des Controllers liegen dann nur in der Zuteilung der jeweiligen Modelklassen zu einer Anfrage. Für jetzt und hier ist dieses Thema jedoch noch zu früh. Auf sinnvolle Architekturen werde ich in einem späteren Teil des Tutorials noch einmal eingehen.

Im Wesentlichen liegt die Aufgabe des Controllers darin, der View-Komponente zu sagen, was sie darstellen soll. Diese Erkenntnis gewinnt er unmittelbar aus dem Request-Objekt und aus dem was der Entwickler festgelegt hat, was er in entsprechenden Fällen zu tun hat. Entsprechend der Anfrage zieht er also das eine oder andere Model-Objekt aus dem Speicher, modifiziert es gegebenenfalls oder erweitert das Datenmodell anhand der im Request-Objekt übermittelten Daten und übergibt diese Teilmenge dem View-Skript. Das wars. Mehr macht der Controller nicht. Ob man dieses Zusammensuchen und Transformieren von Daten nun in eine eigene Modelklasse auslagert, bleibt dann denke ich jedem selbst überlassen.

So das war es für dieses Mal. Ich hoffe euch hat das eher etwas theoretische Tutorial einen Einblick verschaffen können, welche Aufgaben die einzelnen Komponenten des Zend Frameworks übernehmen. Bei Fragen oder Problemen darf natürlich gerne ein Kommentar hinterlassen werden. Der nächste Teil folgt in den nächsten Tagen. Bis dahin wünsche ich allen ein gutes Gelingen.

Ob der Terminator höchstpersönlich auf der Cebit erscheinen wird, ist unklar. In einem Interview sagte er, er würde alles in seiner Macht stehende dafür tun, auf der Messe anwesend zu sein. Aufgrund der kurzen Distanz zum Messegelände und des Besitzes (bisher) einer Freikarte, werde ich in jedem Fall wieder zum ehemaligen Expo-Gelände pilgern und etwas von der großen, weiten IT-Welt in mich aufsaugen. Größter Vorteil dieses Jahr ist, dass ich die Möglichkeit habe auch unter der Woche schon auf die Messe zu gehen. Dadurch kann ich zum einen dem Familien-Beutelratten-Strom ausweichen und zum anderen eine der angekündigten Keynotes lauschen. Um Letztere soll es nun auch im Weiteren gehen, auch wenn man über Beutelratten ebenso locker einen ganzen Blogeintrag füllen könnte.

Die Themen der Keynotes

Während auf der letztjährigen Cebit das Buzzword “Green IT” in aller Munde umhergeisterte, haben sich die Messeplaner es sich nicht nehmen lassen, das diesjährige Programm an einem weiteren auszurichten: Webciety. Eine wunderhübsche Wortschöpfung, wogegen der Rest der Hauptthemen, da bekannt, einem doch eher muffig vorkommen:

• Webciety
• Security
• Green IT
• eHealth
• Mobility

Betrachtet man die Topics der Keynotes der “Global Conferences” vom 3. bis 6. März genauer, darf man jedoch aufatmen, da bis auf Mobility, die anderen Themen weitgehend ausgeklammert bleiben. Am ersten von vier Tagen dreht es sich um die grundsätzlichen Auswirkungen der ICT auf die globale Gesellschaft. Durch Beiträge von Vertretern der Branchengrößen (Microsoft, SAP, Alcatel-Lucent, Intel) und dem anschließenden Panel werden die Weichen gestellt, um den Rest der Woche die technischen Fortschritte, die nicht nur mittels Keynotes, sondern speziell auch durch die vielen Aussteller und deren Produkte, vermittelt werden, besser aufzunehmen und unter einem sozialen, globalen Gesichtspunkt zu sehen.
Am zweiten Tag der Cebit wird die Medienkonvergenz thematisiert. Die Vertreter sind mittels Keynotes T-Mobile, Skype, XING und Acer, sowie im Panel unter anderem Helmut Thoma. Wer den charismatischen Ex-RTL-Chef mag, sollte sich das genau so wenig entgehen lassen, wie die abendlich stattfindende Verleihung des “Convergators Awards”, in dessen Rahmen derselbige eine Laudatio halten wird.
Der vorletzte Tag steht ganz im Zeichen der Wirtschaftskraft, die hinter der ICT steht. Während zum einen Blicke auf die Krise geworfen werden sollen, steht auf der anderen Seite die immense Innovationskraft, die auch in Zukunft die Triebfeder für die Wirtschaft sein soll. In diesem Zusammenhang werden die Vertreter großer Wirtschaftsunternehmen, wie Dell, IBM, Porsche und andere, ihre Visionen für die Zukunft zum Besten geben.
Am vierten und letzten Konferenztag wird noch einmal die Rolle des Internets im Zusammenhang mit der Webciety herausgestellt. Vertreter der Global Player des “Web 2.0″ (Linkedln, Flickr, Yahoo, Amazon, MySpace, Ciao) gehen auf die aktuellen Trends (“Cloud Computing”, Amazon) und die Zukunft des Webs ein.

Und sonst?

Natürlich hat die Cebit neben den offiziellen Konferenzen noch viel mehr zu bieten. Was ich jedoch aus meinen Besuchen auf der Messe bisher gelernt habe, ist sich nicht zu viel vorzunehmen, ansonsten kann einen die Vielfalt an neuen Ideen und Produkten erschlagen. Wer sich für eine der oben genannten Keynotes oder Panels eingetragen hat, kann sich im Zuge dessen auch gleich für eine “Guided Tour” anmelden. So verpasst man für das jeweilige Thema garantiert nichts.
Wer den Luxus hat, mehrere Tage auf die Messe gehen zu können, sollte dies ausnutzen. Ansonsten muss man zwangsweise Abstriche machen. Auf jeden Fall zu empfehlen ist Halle 9. Dort befindet sich neben den Ständen der einzelnen Bundesländer auch der Future Parc. Verschiedene Institute präsentieren hier ihre neuesten Forschungsergebnisse. Gerade das Fraunhofer Institut ist in dieser Beziehung meist für eine Überraschung gut. Ansonsten dürfte es dieses Jahr wohl in der Halle 6 zu Gedränge kommen. Neben dem Hauptpavillon Kaliforniens, wo man im Zweifelsfall den Governator antreffen dürfte, sind hier die Internet & Mobile Solutions zu finden, welche eines der Hauptthemen dieses Jahr darstellen. Was gegen Abend auch immer zu empfehlen ist, sind die Partystände, an denen man den stressigen Messealltag ausklingen lassen kann.

Also denn, vielleicht sieht man sich ja dann im März, wenn es heißt: I’ll be back …

Wer braucht was?

Wer ein Impressum benötigt ist gesetzlich geregelt. Zum einen geht dies aus dem Telemediengesetz (TMG) und zum anderen aus dem Rundfunkstaatsvertrag (RStV) hervor. Der §55 RStV unterscheidet zwei Arten von Telemedien. Zum einen besagt er, dass “Telemedien, die nicht ausschließlich persönlichen oder familiären Zwecken dienen”, folgende Angaben machen müssen:

• Name und Anschrift des Anbieters
• handelt es sich beim Anbieter um eine juristische Person, Name und Anschrift des gesetzlichen Vertreters
• handelt es sich um einen journalistisch-redaktionellen Telemediendienst, jeweils den Namen und die Anschrift des für den jeweiligen redaktionellen Bereich Verantwortlichen

Neben dem Rundfunkstaatsvertrag regelt das Telemediengesetz die Informationspflicht eines Anbieters. Aus §5 TMG geht hervor, dass Diensteanbieter – zusätzlich zu oben genannten Informationen – “für geschäftsmäßige, in der Regel gegen Entgelt angebotene Telemedien folgende Informationen leicht erkennbar, unmittelbar erreichbar und ständig verfügbar zu halten” haben:

• Angaben, die eine schnelle elektronische Kontaktaufnahme und unmittelbare Kommunikation mit ihnen ermöglichen (EMail-Adresse, etc.)
• Aufsichtsbehörde bei Diensten die einer Zulassung bedürfen
• Registernummern und Bezeichnung der Register in die der Anbieter eingetragen ist (HRB, etc.)
• Umsatzsteueridentifikationsnummer (wenn vorhanden)
• Zusätzliche Angaben bei bestimmten Berufsgruppen
• Angabe, ob sich die Kapitalgesellschaft in Liquidation befindet

Die Two-Step-Regel

Nach aktueller Rechtssprechung muss ein Impressum mit zwei Links gefunden werden können. Ein Link mit der Bezeichnung “Kontakt” hinter dem sich der Link “Impressum” verbirgt, wäre demnach noch zu vertreten. Es gibt jedoch auch die andere Seite der Rechtssprechung, wonach ein Link zum Impressum, den man nur durch Scrollen finden kann, unzulässig ist. Möchte man auf Nummer “Sicher” gehen, sollte man das Impressum also leicht findbar auf der Startseite integrieren. Üblicherweise wird es auch im Footer der Seite eingebunden, was zwar der Nicht-Scroll-Regel widerspricht, aber da es der Nutzer dort erwartet, trotzdem leicht zu finden ist. Normalerweise spricht ja aber auch nichts dagegen, dass der Nutzer das Impressum schnell findet. Im Gegenteil. Da im Impressum die Kontaktdaten enthalten sind und eine Kontaktaufnahme von Seiten des Nutzers eigentlich immer erwünscht sein sollte.

Fazit: Mehr ist manchmal weniger

Was lässt sich nun also abschließend zu sagen? Kommerzielle oder redaktionell arbeitende Dienste benötigen in jedem Fall ein ausführiches Impressum. Private Webseitenbetreiber haben grundsätzlich keine Impressumspflicht. Da das Abwägen, ob man wirklich keine geschäftsmäßigen Informationen bereitstellt nicht unbedingt trivial ist, sollte man darüber nachdenken, in jedem Fall ein Impressum mit Name, Anschrift und Kontaktmöglichkeit anzubieten. Mehr Angaben reduzieren das Risiko einer Abmahnung auf eine Wahrscheinlichkeit von 0%. Mehr ist als manchmal doch weniger

Deswegen hier vorerst einmal Linktipps:

• zfwiki.de
• Zend Framework Tutorial für Anfänger
• Einsteigerfragen

Für ein generelles Verständnis halte ich die beiden Teile dennoch nach wie vor geeignet.

Anlässlich eines Projektes, welches ich mit dem Zend Frameworks umsetzen möchte, dachte ich mir, dass ich gleichzeitig meine Ergebnisse im Rahmen eines Tutorials festhalte, da deutsche Tutorials zu diesem Thema rar sind oder zumindest ab einem bestimmten Punkt nicht mehr weiter geführt wurden. Dementsprechend klopfe ich mal auf Holz, dass ich das Ding hier durchziehe

Version und Voraussetzungen

Zum jetzigen Zeitpunkt (Jan ’09) hat das Framework die Version 1.7.2. Zusätzlich zu den Systemvoraussetzungen, sollte auch jeder prüfen, ob der Einsatz eines Frameworks für das jeweilige Projekt gerechtfertigt ist, was folgender Abschnitt versucht herauszustellen.

Wozu ein Framework und warum Zend?

Zunächst möchte ich die Eigenschaften und Vorteile des Frameworks herausgreifen. Mit Hilfe derer sollte jeder noch einmal genau überlegen, ob er der Komplexität des Frameworks gewachsen ist und die daraus entstehenden Vorteile überhaupt benötigt oder nicht. Diejenigen, die sich dessen sicher sind, können diesen Abschnitt getrost überspringen und direkt mit dem Abschnitt “Download & Installation” beginnen. Blutige Anfänger, die bisher noch nie etwas mit PHP oder anderen serverseitigen Skriptsprachen zu tun hatten, sollten sich zunächst durch eines der zahlreich existierenden PHP-Anfänger-Tutorials durcharbeiten. Das wohl bekannteste – mit dem auch meine Wenigkeit vor einigen Jahren begonnen hat – ist wohl das PHP-Tutorial von Quakenet.

Aber nun zu den Vorteilen und Stärken des Zend Frameworks.

Die Stärken des Frameworks liegen grob gesagt in zwei Bereichen. Zum einen erweitert es, wie die meisten Frameworks, die PHP-Standardbibliothek um einen nicht unerheblichen Teil an zusätzlichen Klassen (Caching, Datenbank, Userverwaltung, …) und APIs zu anderen Diensteanbietern (Google, Youtube, …). Auf der anderen Seite bietet es die Möglichkeit mit relativ geringem Aufwand seine Projekte in einer sauberen Architektur (MVC, Webservices) umzusetzen. Letzteres benötigt eine gewisse Einarbeitungszeit in die Systematik, wie das Framework MVC umsetzt. Dies kann auf den ersten Blick mühsam erscheinen, lohnt sich aber, da durch die Architektur automatisch eine Trennung der drei Einheiten Datenmodell, Programmlogik und Präsentation erfolgt. Daraus resultiert, vor allem in großen Projekten mit mehreren Entwicklern und Spezialisten (Datenbankprogrammierer, Webdesigner, …), durch die solide Schnittstellendefinition, eine höhere Stabilität bei Änderungen während der Entwicklungsphase und eine höhere Wartungsfreundlichkeit nach der Auslieferung. Alles in allem wird dadurch die Fehleranfälligkeit reduziert. Durch eine integrierte Testumgebung (Zend_Test) lassen sich zudem sehr schnell Unit-Tests erstellen, wodurch sich das Risiko der Fehlerproduktion beim Refactoring oder bei der Umsetzung von Änderungsanforderung während der Entwicklungsphase reduzieren (C.R.A.P. Index) lässt. Wer sich mehr mit dem Thema “Qualitätssicherung in PHP-Projekten” befassen möchte, empfehle ich den Blog von Sebastian Bergmann (PHPUnit, ezComponents). Für Einsteiger ist eventuell diese Präsentation hiilfreich.

Ein weiterer Vorteil des Zend Frameworks ist die sehr gute Dokumentation. Außerdem erfreut es sich – Open Source sei Dank – einer recht großen und aktiven Community, innerhalb welcher sich auch ein deutschsprachiges Forum etabliert hat.

So viele Möglichkeiten das Framework auch bietet, für die meisten kleinen Projekte, innerhalb derer weder eine Datenbank noch eine Userverwaltung benötigt wird, bringt es einen unvertretbaren Overhead an Speicherplatz und Einrichtungs- bzw. vor allem auch Einarbeitungszeit mit sich. Sobald man sich aber dafür entscheidet ein etwas größeres Projekt umzusetzen, welches eine klar strukturierte Architektur haben oder mittels kleinen Widgets verschiedene Webservices nutzen soll, ohne dass man dabei auf fertige Produkte oder Teilprodukte zurückgreifen will, ist das Zend Framework eine mehr als in Erwägung zu ziehende Alternative.
Eventuell lohnt sich aber auch ein Blick auf Konkurrenzprodukte, wie zum Beispiel CakePHP oder Symfony.

So nun aber los:

Download & Installation

Zunächst beginnen wir mit dem Download der benötigten Komponenten. Um das Framework herunterladen zu können, muss man sich erst einmal registrieren. Je nachdem, wie die spätere Anwendung konzipiert ist, muss man an der Stelle schon die erste Entscheidung treffen, ob man das All-Inclusive-Paket (ca. 25MB, zip) oder die Minimalversion (ca. 4MB, zip) von der Herstellerseite herunterladen möchte.
Für Einsteiger und Leute, die später mit dem Dojo Toolkit arbeiten möchten empfehle ich die Vollversion herunterzuladen, da hier das Dojo Toolkit und einige Demos enthalten sind, die man sehr leicht ausprobieren und anschließend anhand des Quelltextes nachvollziehen kann.
Für eine lokale Testumgebung bietet sich eine Xampp-Installation mit einem Editor nach Wahl (z.B. Aptana Studio oder als Plugin für Eclipse) an. Da das Framework für die Umsetzung einer MVC-Architektur eingesetzt werden soll, empfiehlt es sich, die auf der Herstellerseite vorgeschlagene Verzeichnisstruktur zu übernehmen.
Diese wird im htdocs-Verzeichnis des Apachen angelegt und sieht dann für ein Beispielprojekt “XSampleBlog”, folgendermaßen aus:

htdocs/XSampleBlog/
|
|- application/controllers/
|
|- application/views/
|
|- application/views/scripts
|
|- library
|
|- public

Nun werden die Klassen des Frameworks, welche sich im library-Verzeichnis der entpackten Dateien (ZendFramework-1.x/library/) befinden, in das library-Verzeichnis unserer soeben erstellten Dateistruktur kopiert. Damit ist die “Installation” abgeschlossen.

Zugriffsschutz und Rewriting mittels htaccess

Da nur die Dateien, die sich im Verzeichnis “public” befinden, öffentlich zugänglich sein sollen, heißt das im Umkehrschluss, dass man die beiden anderen Verzeichnis vor einer Auslieferung durch den Webserver bewahren muss. Da man bei den meisten Webhostern auf die direkte Konfiguration des Webservers keinen Einfluss hat, bleibt nur die Konfiguration mittels htaccess-Dateien. Die beiden Verzeichnisse werden also jeweils mittels einer htaccess-Datei mit folgendem Inhalt bestückt, was eine Auslieferung durch den Webserver verhindert (Vertiefung):

Außerdem muss der Apache so konfiguriert werden, dass die Variable $_SERVER['DOCUMENT_ROOT'] auf das public-Verzeichnis verweist. In dieses Verzeichnis wird anschließend eine htaccess-Datei mit Rewrite-Regeln abgelegt. Diese Regeln sorgen dafür, dass für eine gegebene URL, die jeweilige Datei (falls existent) statisch ausgeliefert wird, oder in allen anderen Fällen, die Anfrage dynamisch von der im public-Ordner abgelegten index.php behandelt wird. Die index-Datei entspricht somit einem sogenannten Frontcontroller, welcher alle Anfragen des Nutzers empfängt und an den konkreten Controller übergibt.

Anlegen der bootstrap- und index-Datei

Der nächste Schritt ist das Anlegen der bootstrap- und der index-Datei. Die erstere wird von der zweiten eingebunden. Der funktionale Ablauf ist folgender:

1. Setzen von globalen Pfadangaben (APPLICATION_PATH) (index.php)
2. Aktivieren des Zend_Loader (index.php)
3. Definition von globalen Konstanten (APPLICATION_PATH, APPLICATION_ENVIRONMENT) (bootstrap.php)
4. Erzeugen einer Singleton-Instanz des Zend_Controller_Front (bootstrap.php)
5. Registrieren des controller-Verzeichnisses am Frontcontroller (bootstrap.php)
6. Registrieren des env-Parameters (development, staging, testing, production) am Frontcontroller (bootstrap.php)
7. Löschen der eben erzeugten Variable $frontcontroller (bootstrap.php)
8. Dispatchen des Requests am Frontcontroller (index.php)

Erläuterungen:
zu 7.: In Schritt 4 wurde die Frontcontroller-Instanz an eine Variable gebunden. Da der Frontcontroller jedoch das Singleton-Pattern implementiert, wird diese Variable nicht mehr benötigt und daher gelöscht.

Die Quellcodes für die beiden Dateien sind auf der Herstellerseite zu finden. Damit ist die Anwendung vorerst ausreichend konfiguriert, um nun endlich unsere “Hello World!”-Ausgabe erzeugen zu können.

Hello World!

Unter der Haube wird vom Frontcontroller der Request anhand der übermittelten URL an einen Actioncontroller übergeben. Dies geschieht natürlich nicht willkürlich, sondern folgt folgender Gesetzmäßigkeit. Nehmen wir einmal an, dass die URL “example.com” auf unser public-Verzeichnis zeigt. Wird mit der URL kein weiterer Parameter übergeben, wird am Actioncontroller “IndexController” die Methode “indexAction” aufgerufen. Das selbe Ergebnis würde auch sowohl mit der URL “example.com/index” als auch mit der URL “example.com/index/index” erreicht. Das Schema ist also:

. Nach diesem Prinzip lassen sich weitere Actioncontroller bzw. deren Methoden aufrufen.
Besteht ein Klassen- bzw. Methodenname aus mehreren Wörtern, wie im Fall von “HelloWorld” mit der zugehörigen Methode “sayHello”, erfordert dies eine URL mit dem Wert “example.com/hello-world/say-hello” oder “example.com/hello.world/say.hello”. In diesem Falle wird dann am Actioncontroller mit dem Namen “HelloWorldController” die Methode mit dem Namen “sayHelloAction” aufruft. In unserem Fall sieht die Klasse “HelloWorldController” wie folgt aus:

class HelloWorldController extends Zend_Controller_Action {

    public function indexAction() {
        $this->render('say-hello');
    }

    public function sayHelloAction() {
    }

}

Unsere “Hello World!”-Klasse hat zwei Methoden. Die Methode “indexAction” wird aufgerufen, wenn die URL nur einen Parameter enthält, nämlich den der Klasse. Dieses Prinzip ist analog zu der Eigenschaft des Apache Webservers Requests, die nicht auf eine bestimmte Datei zeigen, auf die index-Datei des jeweiligen Ordners weiterzuleiten. In unserem Fall ruft die Methode “indexAction” die render()-Methode auf mit dem Wert “say-hello”. Dies hat zur Folge, dass das View Skript mit dem Pfadnamen

gerendert wird. Genau das selbe passiert auch implizit, wenn man diesen Parameter über die URL mitgibt. In dem Fall wird nämlich die zweite Methode unserer Klasse aufgerufen, also “sayHelloAction”. Da hier kein expliziter render-Aufruf enthalten ist, wird standardmäßig das View Skript gerendert, welches den per URL übergebenen Parametern entspricht. Ein Beispiel für eine phtml-Datei gibt es hier.

Das war’s. Bei Fragen oder Problemen darf gerne ein Kommentar hinterlassen werden.

Weiterlesen: Zend Framework – Tutorial 2. Teil – Von der Anfrage zum Controller