1.3 Das Galileo-Press-Blog

Wir haben uns entschieden, Ihnen die Konzepte der eZ Components anhand einer realitätsnahen Beispielanwendung zu erläutern. Natürlich handelt es sich bei dem in diesem Buch entwickelten Galileo-Press-Blog (hier kurz GP-Blog genannt) nicht um eine Anwendung, die Sie sofort auf Ihrem Server installieren und einsetzen sollten. Dazu fehlen ihr zum einen einige wichtige Features, zum anderen wurde an einigen Stellen der Übersicht wegen auf wesentliche Teile verzichtet. Dennoch denken wir, dass Ihnen die Einbettung in einen festen Kontext und die praxisorientierte Entwicklung der Beispiele hilft.

Natürlich sind Sie herzlich eingeladen, unsere Beispielapplikation als Grundlage für eigene Entwicklungen und Experimente zu verwenden. Spielen Sie mit den Komponenten, entwickeln Sie die Applikation mit Hilfe der eZ Components weiter und experimentieren Sie mit der Verfeinerung und Erweiterung von Features. Mit dieser Herangehensweise erzielen Sie sicherlich den größten Lernerfolg und sind schnell in der Lage, eigene Anwendungen auf Basis der eZ Components zu erschaffen.

1.3.1 Was soll entwickelt werden?

Als Beispielanwendung wird in diesem Buch eine rudimentäre Weblog-Software entwickelt. Ein Weblog (auch Blog genannt) erlaubt es dem Autor, Einträge zu verfassen und zu speichern sowie Bilder hochzuladen, um sie in den Einträgen zu verwenden. Nicht nur einzelne Bilddateien können hochgeladen werden, sondern auch ganze Archive von Bildern, wobei natürlich jedes Bild entsprechend skaliert und bearbeitet wird. Die Darstellung der Einträge kann sowohl im HTML-Format als auch in verschiedenen Feed-Formaten erfolgen. Ebenso können Besucher der Seite Kommentare hinterlassen. Auch soll die Benutzer-Schnittstelle der Software mehrsprachig verfügbar sein, sodass sowohl englische als auch deutsche Benutzer direkt in ihrer Landessprache arbeiten können. Auch an mobile Blogger wird gedacht und das Erstellen von Einträgen per E-Mail ermöglicht. Schließlich werden Statistiken zu Besucherzahlen und Abrufen des Blogs generiert.

1.3.2 Aufbau der Beispielanwendung

Neben dem objektorientierten Entwurf der Applikation, dem wir uns in Kapitel 3, »Die Applikationsbasis«, widmen, gehört die Struktur der verwendeten Verzeichnisse und der zugrunde liegenden Datenbank zu den wichtigsten Punkten.

Die Verzeichnisstruktur

Im Laufe des Buches werden wir eine Vielzahl verschiedener Dateien erstellen, vorrangig mit PHP-Code als Inhalt, aber auch Konfigurationsdateien, Bilder und andere. Diese Dateien sollen von Beginn an strukturiert werden, damit Sie zu jeder Zeit wissen, wo Sie ein bestimmtes Beispiel auf der Buch-CD wiederfinden können. Hierzu ist folgende Verzeichnisstruktur vorgegeben:

• autoload/ In diesem Verzeichnis liegen PHP-Dateien, die das automatische Laden von PHP-Klassen unterstützen. Mehr zum Thema Autoload erfahren Sie in Kapitel 2, »Einführung in eZ Components«.

• classes/ Die Klassen zur verwendeten Objektstruktur werden bis auf einige Ausnahmen, die in Kürze vorgestellt werden, in diesem Ordner residieren.

• config/ In Kapitel 5, »Konfiguration«, werden Konfigurationseinstellungen, die im vorherigen Kapitel im PHP-Code über Konstanten definiert wurden, in eigene Konfigurationsdateien ausgegliedert, welche dann in diesem Verzeichnis landen.

• docs/ Falls Sie das GP-Blog in seinen einzelnen Stadien direkt ausprobieren wollen, finden Sie in diesem Verzeichnis jeweils wichtige Hinweise, was zu beachten ist.

• exceptions/ Zwar sind Exceptions ebenfalls Klassen, wir werden sie jedoch gesondert aufbewahren, damit keine Verwirrung mit den Klassen der Business-Logik entsteht.

• htdocs/ Wahrscheinlich verwenden Sie selbst ein Verzeichnis, das htdocs/, www/, html/ oder ähnlich heißt, in dem alle aus dem Web direkt aufrufbaren Dateien enthalten sind. Damit ein potentieller Angreifer keinen Zugriff auf weitere Dateien erlangen kann, wird in diesem Verzeichnis nur die Datei index.php, über die alle dynamischen Zugriffe abgewickelt werden, aufbewahrt sowie statische Dateien, wie etwa Bilder und Stylesheets.

• interfaces/ Um den Überblick über definierte Schnittstellen zu behalten, wird für diese ein eigenes Verzeichnis bereitgestellt.

• persistent/ Die PersistentObject-Komponente benötigt spezielle Konfigurationsdateien, welche an dieser Stelle aufbewahrt werden. Mehr Aufschluss dazu bietet das Kapitel 7, »ORM mit PersistentObject«.

• templates/ und templates_c/ Die in eZ Components enthaltene Template-Engine muss zum einen auf die Template-Dateien zugreifen können. Zum anderen werden die kompilierten Versionen der Templates in einem extra dafür bereitgestellten Verzeichnis gelagert. Das Verzeichnis Templates/ fungiert als Speicher für die eigentlichen Template-Dateien, Templates_c/ für die kompilierten Varianten. Achten Sie darauf, dass dem Verzeichnis Templates_c/ unbedingt Schreibrechte für Ihren Webserver zugewiesen sein müssen, da die Templates bei der ersten Verwendung oder bei Änderungen automatisch kompiliert werden.

Die Datenbankstruktur

Als Informationsspeicher wird im GP-Blog ab Kapitel 6, »Datenbankanbindung«, eine Datenbank Verwendung finden, deren Struktur wir bereits an dieser Stelle vorstellen wollen. Drei verschiedene Objekte werden dabei im Laufe der Entwicklung im Datenbanksystem landen:

• Blog-Einträge Ein Blog-Eintrag sollte immer einen Titel und einen Inhalt besitzen. Außerdem ist beim Bloggen inhärent, ein Veröffentlichungsdatum für jeden Beitrag zu speichern. Ebenso ist (ebenfalls ein Trend in den letzten Jahren) die Kennzeichnung eines Eintrags durch sogenannte Tags ebenfalls sinnvoll. Die Tags werden jedoch nicht in der gleichen Tabelle wie die Blog-Einträge gespeichert.

• Kommentare Besucher des GP-Blogs können Kommentare hinterlassen. Diese müssen natürlich ebenfalls gespeichert werden und enthalten den Namen des Besuchers, einen Titel und den eigentlichen Kommentar sowie eine Referenz auf den Blog-Eintrag.

• Tags Ein Tag ist ein Schlagwort, das einen Beitrag inhaltlich charakterisiert. Durch eine Menge von Tags kategorisiert man einen Beitrag und gibt implizit Verknüpfungen zu ähnlichen Inhalten an: Einträge, bei denen viele Tags übereinstimmen, sind verwandt. Wenn Sie zum Beispiel einen Blog-Eintrag über dieses Buch schreiben wollen, können Sie diesen mit den Tags PHP, Bibliothek, eZ Components und Buch beschreiben. Ein Tag kann somit mehreren Einträgen zugeordnet sein; und ein einzelner Eintrag kann mehrere Tags haben.

• Neben diesen drei Basistabellen, welche die eigentlichen Daten speichern, benötigen wir eine Verknüpfungstabelle zwischen Einträgen und Tags, da es sich hier um eine n:m-Relation handelt: Ein Eintrag kann n Tags besitzen; ein Tag kann ebenfalls m Beiträgen zugeordnet werden. Das folgende SQL-Schema zeigt diese Struktur:

CREATE TABLE "comment" (
  id int(10) unsigned NOT NULL auto_increment,
  entry_id int(10) unsigned NOT NULL,
  "name" varchar(80) NOT NULL,
  email varchar(80) NOT NULL,
  body text NOT NULL,
  "date" int(10) unsigned NOT NULL,
  PRIMARY KEY  (id)
);
CREATE TABLE entry (
  id int(10) unsigned NOT NULL auto_increment,
  title varchar(255) NOT NULL,
  body text NOT NULL,
  "date" int(10) unsigned NOT NULL,
  PRIMARY KEY  (id)
);
CREATE TABLE entry_tag (
  entry_id int(10) unsigned NOT NULL,
  tag_id int(10) unsigned NOT NULL,
  PRIMARY KEY  (entry_id,tag_id)
);
CREATE TABLE tag (
  id int(10) unsigned NOT NULL auto_increment,
  tag varchar(30) NOT NULL,
  PRIMARY KEY  (id),
  UNIQUE KEY tag (tag)
);
CREATE TABLE access (
  `date` bigint(20) NOT NULL,
  browser varchar(32) NOT NULL,
  os varchar(32) NOT NULL,
  language varchar(8) NOT NULL,
  type varchar(8) NOT NULL,
  data varchar(255) NULL,
  KEY `browser` (`browser`),
  KEY `os` (`os`),
  KEY `type` (`type`),
  KEY `date` (`date`)
);

Listing 1.1 Datenbankschema des GP-Blogs

Wie Sie sicherlich feststellen, handelt es sich um die Struktur einer MySQL-Datenbank. Sollten Sie ein anderes Datenbanksystem präferieren, können Sie dieses Schema leicht an Ihre Datenbank anpassen. In Kapitel 18, »Setup«, wird zusätzlich ein abstraktes Schema-Format vorgestellt, das Sie mit Hilfe der Komponente DatabaseSchema in eine beliebige Datenbank importieren können. Einzige Voraussetzung für die Verwendung mit dem GP-Blog ist, dass die Database-Komponente die Datenbank Ihrer Wahl unterstützt. Bisher ist dies der Fall für MySQL, Oracle, SQLite, PostgreSQL und MS SQL Server.

1.3.3 Testen des GP-Blogs

Ab Kapitel 3, »Die Applikationsbasis«, haben Sie die Möglichkeit, die im Verlauf des Buches entwickelte Beispielanwendung direkt im Quellcode nachzuvollziehen und gleichsam zu testen. Zu jedem Kapitel, in dem eine Erweiterung des GP-Blogs stattfindet, existiert auf der Buch-CD ein entsprechendes Verzeichnis, in dem die Erweiterungen gegenüber dem letzten Kapitel eingeflossen sind. Hier können Sie nicht nur den Sourcecode wiederfinden, der im entsprechenden Kapitel besprochen wurde, sondern meistens auch weitere Beispiele zum aktuellen Thema.

Die Beispielverzeichnisse sind jeweils mit dem Namen stageXY/ benannt und der Reihenfolge nach durchnummeriert. Die erste Version zu Kapitel 3, »Die Applikationsbasis«, finden Sie also im Verzeichnis stage01/, die erweiterte Version zu Kapitel 4, »Fehlerbehandlung und Debugging«, entsprechend in stage02/ und so weiter. Zum Testen der Applikation benötigen Sie einen geeigneten Webserver, der einen Mechanismus ähnlich dem Modul mod_rewrite [http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html ] des bekannten Apache-Webservers unterstützt, um die korrekte Funktion zu gewährleisten, wie zum Beispiel Lighttpd [http://www.lighttpd.net/ ] .

Kopieren Sie zum Testen des GP-Blogs einfach das entsprechende stageXY-Verzeichnis auf die Festplatte. Lediglich der htdocs-Ordner einer jeden Stage muss durch den Webserver zugreifbar sein, was auch sicherheitstechnischen Aspekten entspricht. Im Verlauf des Buches setzen wir voraus, dass Sie einen virtuellen Host namens gpblog eingerichtet haben. Die Tests können aber auch mit jedem anderen Hostnamen oder mittels Aufruf per IP-Adresse erfolgen.

Lediglich die gezeigten Beispiel-URLs müssen entsprechend Ihrer Umgebung angepasst werden. Verwenden wir im Buch eine URL wie beispielsweise http://gpblog/entry_edit/1, müssen Sie den Hostnamen anpassen, falls Sie nicht gpblog verwenden, und entsprechende Verzeichnisebenen einfügen, falls Sie nicht nur das htdocs-Verzeichnis der zu testenden Stage eingebunden haben. Sofern Sie also keinen speziellen Hostnamen verwenden und alle Stages einfach ins Basisverzeichnis Ihres Webservers kopiert haben, müsste die gezeigte URL wie folgt angepasst werden: http://localhost/stage01/htdocs/entry_edit/1.

Das erwähnte Rewrite-Modul wird in jedem Fall benötigt, um eine korrekte Abbildung der URLs auf einzelne Aktionen des GP-Blogs zu gewährleisten. Dabei müssen URLs, die keine index.php-Datei enthalten, so umgeschrieben werden, dass die Datei enthalten ist. Dies führt zu optisch ansprechenderen URLs und garantiert, dass die Url-Komponente korrekte Links erzeugt, denn diese Komponente setzt den Rewrite-Mechanismus voraus. Näheres zu den Themen Dispatching und Aktionen erfahren Sie in Kapitel 3, »Die Applikationsbasis«.

1.3.4 Rewriting einrichten

Wir empfehlen Ihnen zum Testen den Webserver Lighttpd, einen schlanken, stabilen und schnellen Webserver, der von Jan Kneschke entwickelt wurde. Die Einrichtung dieses Webservers ist wesentlich komfortabler und einfacher als die Einrichtung eines Apache-Webservers. Einige bekannte, hoch frequentierte Webseiten setzen bereits auf Lighttpd, wie zum Beispiel die Upload- und Download-Seiten der Wikimedia Foundation [http://meta.wikimedia.org/wiki/Wikimedia_Foundation ] , der Betreiber der bekannten Web-Enzyklopädie Wikipedia. [http://wikipedia.org ] Weitere Informationen und eine ausführliche Dokumentation zur Einrichtung von Lighttpd finden Sie auf der Webseite des Open-Source-Projekts unter http://www.lighttpd.net/. Sollten Sie jedoch bereits einen Apache-Webserver installiert und eingerichtet haben, können Sie auch diesen zum Testen verwenden. Wir gehen an dieser Stelle kurz auf beide Konfiguration für das GP-Blog ein.

Rewriting mit Lighttpd

Im Fall von Lighttpd funktioniert das Rewriting mittels Perl-kompatibler regulärer Ausdrücke (PCRE). Zunächst müssen Sie das entsprechende Modul in Ihrer Konfigurationsdatei lighttpd.conf aktivieren. Die passende Direktive mit dem Namen mod_rewrite ist in der mitgelieferten Beispielkonfiguration bereits enthalten und lediglich auskommentiert. Anschließend müssen Sie das Rewriting konfigurieren, was hier exemplarisch für die in diesem Buch verwendeten Links dargestellt ist:

$HTTP["host"] =~ "^gpblog$" {
    server.document-root = "/var/www/gpblog/stage01/htdocs"
    url.rewrite-once = (
        "^/(?!(index\.php|styles|images))(.*)$" =>
        "/index.php/$1"
    )
}

Listing 1.2 Lighttpd Rewrite-Konfiguration

Die hier gezeigte Konfiguration definiert einen virtuellen Host mit dem Namen gpblog, womit URLs verarbeitet werden können, wie sie in diesem Buch gezeigt werden. Vergessen Sie nicht, dass Sie beim Verwenden eines Hostnamens eine korrekte Auflösung des Namens auf Ihren Rechner anlegen müssen. Die document-root-Variable müssen Sie entsprechend auf Ihre Umgebung und das gewünschte stageXY/-Verzeichnis anpassen. Die rewrite-once-Variable besteht aus einer Art Array-Struktur, wie sie aus PHP geläufig ist. Einem regulären Ausdruck wird jeweils die zu erzeugende URL zugeordnet. rewrite-once bedeutet, dass der Rewrite-Vorgang nur ein Mal ausgeführt werden soll und nach dem ersten Treffen einer Regel beendet ist. Alle URLs, die am Anfang nicht die Zeichenketten index.php, styles oder images aufweisen, werden umgeschrieben. Verwenden Sie eine tiefere Verzeichnishierarchie, müssen Sie beide Pfade entsprechend anpassen, indem Sie den benötigten Verzeichnisanteil voranstellen.

Nach einem Neustart des Lighttpd-Servers sollte Ihre Testumgebung erfolgreich eingerichtet sein.

Rewriting mit Apache

Die Definition von virtuellen Hosts funktioniert in Apache ähnlich wie in Lighttpd, auch wenn das Format der Konfiguration eine andere Form aufweist. Bevor Sie das Rewriting einrichten können, müssen Sie zuerst das entsprechende Modul mit dem Namen mod_rewrite aktivieren. Wie die passende Konfigurationsdatei heißt, ist von System zu System verschieden, meist ist es jedoch httpd.conf oder apache.conf. Anschließend wird das Rewriting konfiguriert, was hier wieder exemplarisch für die im Buch verwendeten Links gezeigt wird:

<VirtualHost *:80>
  ServerName gpblog
  DocumentRoot /var/www/gpblog/stage01/htdocs
  <Directory />
    RewriteEngine on
    RewriteCond %{SCRIPT_FILENAME} !-f
    RewriteCond %{SCRIPT_FILENAME} !-d
    RewriteRule ^(.*)$ index.php
  </Directory>
</VirtualHost>

Listing 1.3 Apache Rewrite-Konfiguration

Wieder wird ein virtueller Host eingerichtet, der auf den Hostnamen gpblog reagiert. Wie beim Lighttpd-Beispiel bereits erwähnt, müssen Sie den Pfad zu DocumentRoot entsprechend Ihrer Umgebung anpassen. Die Rewrite-Konfiguration prüft zunächst, ob die angefragte Datei physisch existiert und leitet gegebenenfalls über die Datei index.php um, wenn dem nicht so ist. Wir wollen die Konfiguration von Apache-mod_rewrite an dieser Stelle nicht weiter vertiefen, dafür ist die Konfiguration des Moduls zu komplex. Sollten Sie Unterstützung benötigen, so finden Sie eine ausführliche Dokumentation unter http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html.

Konfiguration anpassen

Neben dem Rewriting müssen Sie innerhalb des GP-Blogs noch Konfigurationseinstellungen anpassen. So benötigt die Anwendung ebenfalls Informationen über die von Ihnen verwendete Verzeichnisstruktur, um zum Beispiel URLs korrekt zu erzeugen. In Kapitel 3, »Die Applikationsbasis«, und Kapitel 4, »Fehlerbehandlung und Debugging«, werden diese Konfigurationseinstellungen in der Datei index.php im Verzeichnis htdocs/ als PHP-Konstanten definiert. Ab Kapitel 5, »Konfiguration«, steht hierfür die Configuration-Komponente zur Verfügung und die Einstellungen werden in eine gesonderte ini-Datei ausgelagert. In Kapitel 3, »Die Applikationsbasis«, erfahren Sie mehr darüber, welche Einstellungen Sie anpassen müssen. In Kapitel 5, »Konfiguration«, wird gezeigt, wie die dort neu eingeführten Konfigurationsdateien anzupassen sind.

Ihr Kommentar