Kapitel 1. Einleitung

Inhaltsverzeichnis

1.1. Das Zend Framework
1.2. Über dieses Buch
1.2.1. Quelltexte der Kapitel beziehen
1.3. Ich, Ich, Ich!
1.4. Zu dieser Übersetzung
1.5. Sie, Sie, Sie!

1.1. Das Zend Framework

Seit seiner Veröffentlichung hat das Zend Framework die PHP-Community im Sturm erobert. Seine Herangehensweise an die gesamte Framework-Thematik ist nahezu einzigartig in einer Umgebung, die häufig fest integrierte und restriktive Lösungen für eine breite Palette von Webanwendungsproblemen bevorzugt. Unter PHP-Entwicklern hat sich dieser Ansatz bisher als populär erwiesen.

Das Konzept, welches hinter dem Zend Framework steht ist, die Erstellung von Web-Anwendungen einfacher, leichter und schneller zu gestalten. Die meisten dieser Ziele werden durch ein Fundament an Quelltext erreicht, das von dutzenden Programmierer entwickelt und mit Unit-Tests gequält wurde, bis es nur noch um Gnade gewinselt hat. Mit diesem Code im Handgepäck besteht für Sie als Entwickler keine Notwendigkeit mehr, dieselbe Arbeit in Ihren Projekten zu wiederholen. Im Wesentlichen können Sie damit den Schritt überspringen, Anwendungsfunktionalitäten zu entwickeln, die bereits in ähnlicher Weise durch das Framework bereitgestellt werden und sich stattdessen mehr auf das konzentrieren, was Ihre Anwendung tatsächlich leisten soll.

Dieser Denkansatz im Bezug auf Frameworks ist stark vereinfacht, vermittelt jedoch den Kern des Ganzen. Über die Jahre haben die Entwickler festgestellt, dass sie eine nahezu lächerliche Menge an Zeit damit verbringen, dieselben Basisfunktionalitäten immer wieder aufs Neue zu entwickeln, wenn sie die Arbeit an einer neuen Anwendung beginnen. Diese Geschichte ist wohl jedem PHP-Entwickler vom Anfänger bis zum Profi bekannt und heutzutage noch genauso frustrierend, wie sie es immer schon war.

Frustrierte Entwickler neigen dazu, eine hohe Motivation zur Beseitigung dieser Frustration zu entwickeln. Über die Jahre haben PHP-Entwickler Bibliotheken, Klassensammlungen, Funktionssammlungen, C-Extensions und sogar Textdateien mit nützlichen Code-Schnipseln gesammelt und gehortet. Ein Webanwendungs-Framework geht hier noch einen Schritt weiter, denn es handelt sich quasi um den Kern einer Anwendung, dem der anwendungsspezifische Quelltext noch fehlt. Dieser Teil ist portierbar, standardisiert, sehr gut getestet und wird auf die Gemeinschaft losgelassen, damit er viele tausend Male wiederverwendet werden kann.

Ein Framework aus den vielen Alternativen auszusuchen ist gerade heutzutage keine einfache Aufgabe, da es üblich und absolut akzeptabel ist, laufend zwischen Frameworks oder gar Programmiersprachen zu migrieren. Beinahe jedes Webanwendungs-Framework wird Ihnen versprechen Ihre Entwicklungsarbeit simpler, einfacher und schneller zu gestalten. Es kommen jedoch eine Menge an weiteren Faktoren hinzu, welche die Entscheidung beeinflussen sollten:

  • Wartbarkeit

  • Adaptierbarkeit

  • Leichtigkeit des Testens

  • Technischer Support und Unterstützung durch die Community

  • Die Qualität der Dokumentation

  • Regelmäßigkeit von Upgrades und Fixes

  • Qualitätskontrolle

  • Grundperformance

  • Die Lernkurve

  • Funktionalitäten und Innovationen

  • Die Möglichkeit des Einsatzes auf Hosting-Paketen

  • Unterstützung aktueller "Best Practices"

  • Literatur und Artikel aus der Community

Diese Liste stellt keinen Anspruch auf Vollständigkeit! In jedem Projekt können je nach Anforderung noch weit spezifischere Faktoren die Entscheidung beeinflussen.

Das Zend Framework schneidet in vielen der oben genannten Punkte gut ab, sicherlich jedoch nicht in allen. Realistisch betrachtet wird es kein Framework geben, welches alle Kriterien erfüllt. Bei der Wahl eines Frameworks muss man immer Kompromisse eingehen - ein Faktum, über das seltener erwähnt wird.

An diesem Punkt bin ich mir sicher, dass zehntausende Entwickler da draußen sind, die weiterhin vorhaben, niemals ein Framework zu verwenden, weil diese böse sind und von fehlinformiertern Fanatikern (wie mir) entwickelt wurden. PHP ist in dieser Hinsicht eigenartig, denn bestimmte Geisteshaltungen scheinen hier nur sehr langsam übernommen zu werden, obwohl sie Prinzipien von Webanwendungs-Frameworks betreffen und in anderen Programmiersprachen schon lange akzeptiert sind. Ein großer Teil davon ist wohl in der Demographie begründet. Unter den PHP-Programmierern gibt es viele Amateurprogrammierer und Autodidakten, da PHP leicht zu lernen ist. Hinzu kommt, dass PHP eine der "ältesten" Sprachen der Web-Entwicklung ist. In diesem Zusammenhang entflammen häufig die Diskussionen um die Sicherheit der Programmiersprache, was jedoch - wenn man es genauer betrachtet - eher ein Programmierer-Problem als ein Problem der Sprache ist. Schlecht informierte Programmierer lesen keine Bücher oder Artikel über Sicherheit und erzeugen erfahrungsgemäß schlecht geschriebenen und unsicheren Quelltext. Ich empfehle dieser Gruppe, ihre Haltung zu überdenken und uneinvorgenommen zu sein. Soweit ich weiß, bin ich nicht böse.

Um das Zend Framework zu verwenden, müssen Sie verstehen, wie es strukturiert und aufgebaut ist. Viele Frameworks folgen hier einem "Ganz oder gar nicht"-Ansatz, bei welchem von Ihnen als Entwickler erwartet wird, dass Sie sich an die Konventionen und Werkzeuge des Frameworks halten und nur minimal davon abweichen. Diese Art von Framework wurde einmal von Chris Hartjes als "full stack framework" bezeichnet, in Anlehnung an die Herangehensweise dieser Frameworks. Man ist "gezwungen", jede Komponente des Frameworks zu nutzen und kann nur wenige oder gar keine externen Bibliotheken verwenden. Einige Beispiele für "full stack frameworks" sind CakePHP, Django (für Python) und Ruby on Rails. Ihnen entgegengestellt hat Chris die sogenannten "glue frameworks", im übertragenen Sinne also verbindende Frameworks. Hier kann der Entwickler nehmen was er benötigt, vorhandene Klassen erweitern, ganze Komponenten ersetzen und die Anwendung stärker nach seinen Bedürfnissen strukturieren. Beispiele für diese Art von Framework sind Code Igniter und ezComponents.

Das Zend Framework ist ebenfalls ein "glue framework". Es bietet alle Funktionalitäten als lose gekoppelte Komponenten an, welche auch unabhängig vom Framework existieren können. Im Grunde handelt es sich um eine Sammlung einzelner Bibliotheken, die an manchen Stellen verbunden sind. Dazu zählt unter anderem die MVC-Komponente, die das Framwork in der Nutzung durch einige Konventionen schnell wie ein "full stack framwork" erscheinen lassen. Der hoch modulare Ansatz repräsentiert einen großen Teil dessen, was das Zend Framework so populär gemacht hat: Jede Komponente und Klasse kann erweitert, dem Framework-Stack zur Kenntnis gebracht und ohne großes Aufheben verwendet werden. Ja, dadurch entsteht ein Mehraufwand (wenn Sie diesen Pfad gehen), aber damit begrenzt nur Ihre Fantasie die Fähigkeiten und Funktionen des Frameworks.

Es existieren Komponenten für Aufgaben, die weit über die eines "full stack framework" hinaus gehen. Die Mitglieder der Community haben Klassen für die Generierung von PDF-Dateien, Cache-Mechanismen, RSS- und ATOM-Verarbeitung, Dojo- und jQuery-Integration, dutzende von Webservice-APIs und unzählige weitere Helfer und Module erschaffen und bereitgestellt. Hinzu kommt, dass Sie nichts daran hindert, diese Zend-Framework-Komponenten in anderen Frameworks wie CakePHP, Symfony oder Code Igniter zu verwenden! Es handelt sich um eine wirklich offene und portierbare Architektur.

Bewerten wir nun das Zend Framework anhand der oben erwähnten Punkte, die bei der Wahl eines Frameworks wichtig sind. Ich habe 13 Punkte (Pech für Einige) aufgeschrieben, die Ihnen als Beispiel dienen sollen.

Wartbarkeit

Das Zend Framework ist leicht wartbar, da es die Erweiterung von Klassen unterstützt, Gebrauch von Interfaces macht, über eine beeindruckende Unit-Testing-Suite verfügt und von der Zend-Framework-Gemeinde dahingehend kontrolliert wird. Verschiedene Maßnahmen gewährleisten, dass die Abwärtskompatibilität erhalten bleibt und Änderungen minimale Auswirkungen auf Ihre bestehenden Anwendungen haben. Dazu zählen der öffentliche Zugang zum Subversion-Repository, Sanity-Releases und der energische Widerstand gegen Verhaltensänderungen der Komponenten.

Adaptierbarkeit

Aufgrund seiner Natur als "glue framework" bietet das Framework ein riesiges Potential für Anpassungen an die eigenen Bedürfnisse. Ich denke, es fehlt nicht an Klassen und Komponenten, die Sie anpassen, erweitern oder schlicht durch existierende Alternativen ersetzen können. Es existiert bereits eine Menge überarbeiteter Komponenten, die Sie außerhalb des Frameworks herunterladen können und die Funktionalitäten anbieten, welche noch nicht in das Framework integriert worden sind.

Lernkurve

Die Lernkurve besteht aus zwei getrennten Abschnitten. Der erste Teil der Lernkurve, der Einstieg, entspricht der jedes anderen Frameworks und wird für Entwickler kein großes Problem darstellen. Hier wird man vor allem durch das exzellente Referenzhandbuch unterstüzt. Im zweiten Teil muss man lernen, wie man die Anpassungsfähigkeit des Frameworks ausnutzen kann, um Plugins, Erweiterungen und auch neue Komponenten zu schreiben, wie es häufig für tatsächliche, reale Anwendungen nötig ist. Hier wird die Kurve sicherlich steiler, da dieses Wissen erst durch Erfahrung entsteht. Dieses Buch wurde geschrieben, um Ihnen bei genau diesem Teil zu helfen.

Funktionalitäten und Innovationen

Dutzende Komponenten, hunderte Klassen, eine kilometerlange Schlange an Vorschlägen für Komponenten: Features gibt es genug! Was Innovationen anbelangt, hat sich das Framework dafür gerüstet, Implementierungen für die neuesten Webtechnologien anzubieten. Größtenteils war es dabei sehr erfolgreich und wie Sie sehen können, enthält das Zend Framework offizielle PHP-Referenz-Implementierungen für Technologien von Google, Adobe und Microsoft.

Qualität der Dokumentation

Es gibt zwei grundlegende Meinungen zur Dokumentation des Frameworks. Beide sind sich einig, dass das Referenzhandbuch unglaublich wichtig ist und den Entwicklern sehr erfolgreich Wissen vermittelt. Während der eine Teil der Benutzer damit sehr zufrieden ist, fällt das Handbuch beim anderen Teil seiner immensen Größe zum Opfer: bestimmte Details sind schwer zu finden und selbst Grundlegendes erscheint mitunter übermäßig kompliziert oder nur schwer entzifferbar. Halten Sie das Handbuch deswegen aber nicht gleich für schlecht! Es übertrifft die Dokumentation vieler lang bestehender Frameworks um Lichtjahre, welche sich kaum die Mühe machen, eine automatisch generierte API-Dokumentation zusammen zu kratzen. Das Referenzhandbuch wird auch ergänzt durch...ja, genau...dieses Buch! Um fair zu sein sollte ich hinzufügen, dass bereits drei andere Bücher über das Zend Framework veröffentlicht wurden und es daher gut dokumentiert ist, doch nur dieses Buch ist kostenlos (Achtung, schamlose Werbung).

Technischer und Community-Support

Ein wichtiges Argument für das Zend Framework ist, dass es die offizielle Unterstützung von Zend Technologies Inc. genießt. Zend beaufsichtigt den gesamten Entwicklungsprozess und gewährleistet somit, dass alle Komponenten durchdacht, geprüft und tatsächlich nutzbar sind. Zend und seine weltweiten Partner bieten zudem Support und Schulungen zu Preisen an, die für viele Unternehmen attraktiv sind. Vonseiten der Community gibt es zahlreiche Mailinglisten, IRC-Kanäle und eine Gemeinschaft von Bloggern, welche sich nur allzu gern in den Wahnsinn treiben lassen, indem sie jede Ihrer skurrilen Fragen beantworten. Abgesehen von den Mailinglisten sind die meisten Community-Ressourcen unabhängig von Zend, ebenso existieren zahlreiche nicht-englische Websites und Foren.

Regelmäßigkeit von Upgrades und Fixes

Updates erscheinen häufig, üblicherweise alle paar Wochen in Form eines "Minor Release", welcher Fehler behebt, neue Funktionalitäten und Verbesserungen bestehender Funktionalitäten enthält. Es gibt keine Releases, die ausschließlich der Behebung von Sicherheitslücken dienen, was problematisch sein könnte, wenn sich kleine Fehler über zu lange Zeit anhäufen; allerdings werden Aktualisierungen häufig und in vorhersehbaren Abständen veröffentlicht, wobei man sich stark an einen vorgegebenen Zeitplan hält.

Qualitätskontrolle

Die Qualitätskontrolle ist Teil des Aufgabenbereichs von Zend, das alle Komponenten überprüft, bevor sie zur weiteren Entwicklung und Veröffentlichung freigegeben werden. Einige Komponenten können qualitativ eindeutig nicht mit dem Rest mithalten, was die Funktionalität, einfache Benutzbarkeit und andere relevante Faktoren betrifft, aber das kommt nur vereinzelt vor; handelt es sich um populäre Komponenten, wird ihnen üblicherweise die nötige Aufmerksamkeit gewidmet, um das zu beheben. Alle Komponenten werden rigorosem Unit-Testing unterzogen und stehen unter dem immer wachsamen Auge der Community. Vor kurzem gab es ein "Bug hunt event", das - wie ich hoffe - zukünftig in gewisser Regelmäßigkeit abgehalten wird.

Grundperformance

Das Thema Grundperformance müssen Sie mit Vorsicht genießen. Jedes Framework hat andere Voraussetzungen und bietet unterschiedliche Features, so dass es schwer (viele würden sogar sagen: sinnlos) ist, diese eins-zu-eins zu vergleichen. Ich möchte damit sagen, dass der vernünftige Einsatz von Caching und Optimierungen die meisten Performance-Vorteile jedes Frameworks über ein anderes aufheben. Bitte vernachlässigen Sie diesen Punkt nicht! Falls Sie jedoch auf die Interpretation von Benchmarks bestehen, dann ist die beste mir bekannte Quelle eine Serie von Benchmark-Tests von Paul M. Jones aus dem September 2008, die März 2009 aktualisiert wurde, um einen kleinen Fehler zu korrigieren. Diese Benchmarks verwenden ausschließlich den Code, der für einen vollständigen Request-/Response-Zyklus notwendig war. Demnach erreichte das Zend Framework auf Pauls Amazon-EC2-Referenzsystem damals 78,93 Anfragen pro Sekunde im Vergleich zu 61,84 Anfragen für Symfony, 42,79 für CakePHP und 138,64 für Solar. Code Igniter wurde nicht gemessen, würde aber angesichts des Zielmarktes und Entwicklungsansatzes wohl die meisten Mitbewerber schlagen. Insgesamt zeigt sich, dass sich das Zend Framework mehr oder weniger im Bereich seiner Hauptalternativen bewegt. Die knappe Führung ist im Rahmen einer Gesamtanalyse meiner Meinung nach vollkommen irrelevant.

Leichtigkeit des Testens

Ich will ehrlich sein. Darüber ärgere ich mich beim Zend Framework am meisten. Wer meinen Blog liest, wird wissen, dass ich mich gerne über Themen wie Behaviour-Driven Design (BDD) oder eXtreme Programming (XP) auslasse. Diese Praktiken verlangen einen bestimmten Grad an Test-Unterstützung, damit wir Fanatiker BDD oder Test-Driven Design (TDD) betreiben können, um unsere Fanatiker-Herzen zufriedenstellen zu können. Das Zend Framework hat sich diesbezüglich - vor allem aufgrund seiner PHP-typischen Denkhaltung - auf spektakuläre Weise in den Fuß geschossen. Es gibt keine interne Test-API! Ich möchte mein Urteil etwas abschwächen, indem ich anmerke, dass es nun eine Zend_Test-Komponente gibt, welche das funktionale Testen viel einfacher macht, wenn Sie PHPUnit verwenden. Die Komponente arbeitet als ein abstrakter Proxy direkt im Inneren der MVC-Komponente und bietet gute Kontrollmöglichkeiten zum Erzeugen von Anfragen (Requests) und Testen von Antworten (Responses). Sie wird nicht jeden zufriedenstellen, aber sie bekommt die grundlegenden Dinge richtig hin und wird für die Mehrheit der PHP-Entwickler ausreichen. Solange die Entwickler ihre Model-Objekte von der Controller- und View-Schicht getrennt halten, sind die Probleme minimal.

Verfügbarkeit von Hosting

Das Zend Frameworks läuft auf PHP. Ernsthaft, muss ich mehr sagen? Ich könnte genau so gut über die Verfügbarkeit von Luft sprechen, oder von Umweltverschmutzung, oder vielleicht über die von Kaninchen? PHP hat etwas mit allen dreien gemeinsam...es ist überall.

Unterstützung aktueller "Best Practices"

Das Zend Framework hatte immer eine Achillesferse: das Testen. Ich habe das Thema bereits behandelt, und abgesehen von diesem Kritikpunkt gibt es nichts, was Entwickler davon abhält, ihre eigene Art von Fanatismus zu entwickeln - oder auch ihre eigene Programmier-Methodologie (was nur für sarkastische Menschen, die sich gern selbst auf die Schippe nehmen, wie Fanatismus klingt...wie mich).

Literatur aus der Community

Zend Framework hat die Community zweifellos äußerst erfolgreich zum Mitmachen ermuntert. Zu jedem denkbaren Thema existiert eine Unmenge an Artikeln, Büchern (inklusive diesem!), Abschnitten in Handbüchern und Blog-Einträgen. Sie wissen, dass dieses Buch hier ehemalig ein bescheidenes Dasein als neunteiliges Tutorial in meinem Blog gefristet hat, richtig?

13 Punkte später denke ich nun, dass ich alle Grundlagen abgedeckt habe. Der Zweck dieser Übung war, Ihnen, den Leserinnen und Lesern, ein wenig Vertrautheit mit dem Zend Framework einzuflößen und fanatischen Eifer in Ihnen zu wecken (so dass Sie weiterlesen und mir eventuell etwas Geld für mein neues Macbook Pro zukommen lassen). So können nun aber auch einen Blick auf andere Frameworks werfen und haben eine Vorstellung davon, worauf Sie dabei achten sollten. Das Leben beginnt und endet nicht mit dem Zend Framework: allerdings sollte es das für die Zeit Ihrer Aufmerksamkeitsspanne, während Sie dieses Buch lesen!

1.2. Über dieses Buch

Zend Framework: Surviving The Deep End ist in Form eines detaillierten Tutorials geschrieben und erstellt Schritt für Schritt eine reale, aus dem wirklichen Leben gegriffene Anwendung. Themen werden - wo sinnvoll - gruppiert und spätere Kapitel verweisen immer wieder auf vorangegangene Kapitel, um das bereits Gelernte zu festigen. Das Buch wurde so konzipiert, dass es Elemente des Referenzhandbuchs, des wachsenden Wissensrepertoires der Community und meiner eigenen Erfahrungen vereint, damit Entwickler die Entstehung einer echten Anwendung auf Basis des Zend Framework in ihrer Gesamtheit kennen lernen können.

Meiner Meinung nach war das Hauptproblem des Frameworks immer, dass das Referenzhandbuch kaum über die Erklärung der einzelnen Framework-Komponenten in vollständiger Isolation hinausgeht. Es bietet keine Entwicklungs- und Denkansätze oder fortgeschrittene Kapitel dazu, wie Komponenten miteinander kombiniert werden. Sie sollten zur Kenntnis nehmen, dass dieses Buch kein Ersatz für das Zend-Framework-Referenzhandbuch ist. Sie können das Handbuch unabhängig davon lesen: es ist kostenlos, detailliert und einigermaßen einfach durchsuchbar. Dieses Buch stellt eine Ergänzung dazu dar, keinen Ersatz.

Das Buch enthält den kompletten Quelltext der Anwendung innerhalb des Textes und wiederholt Codeteile mehrmals, um Änderungen hervorzuheben, die ich am Code vornehme. Ich kann verstehen, dass seitenlange Quelltexte manchmal frustrierend sein können, aber es sie erhöhen die Klarheit und Übersichtlichkeit, was ich sehr schätze. Der Einfachheit halber steht wie unten genauer beschrieben am Ende jedes Kapitels der komplette und finale Code als separater Download bereit.

Im Laufe der Zeit werde ich auf einige externe Frameworks abseits des Zend Framework verweisen, die Sie installieren sollen. Dazu zählen PEAR, das "Blueprint CSS Framework", jQuery, HTMLPurifier und PHPUnit. Ich weiß aus Erfahrung, dass einige Menschen nicht davon begeistert sind, aber ich versichere Ihnen, dass die Installation detailliert behandelt wird und auch für Anfänger einfach zu bewerkstelligen ist. Vergessen Sie nicht, dass eine reale Anwendung ebenfalls zahlreiche externe Bibliotheken benötigt!

Beachten Sie bitte schließlich, dass dieses Buch von grundlegenden Kenntnissen bezüglich PHP 5, SQL und objektorientierter Programmierung (OOP) ausgeht. Dieses Wissen ist notwendig, wenn sie den Umgang mit dem Zend Framework erlernen wollen, wird aber in diesem Buch nicht ausführlich besprochen. Da PHP aber so einfach zu erlernen ist, zweifle ich nicht daran, dass Sie online zahllose Ressourcen finden können, die Ihnen am Anfang Ihres Weges zum Status eines PHP-Guru helfen.

1.2.1. Quelltexte der Kapitel beziehen

Der Quelltext für alle Kapitel wird offen zugänglich auf Github.com unter Verwendung eines git-Repository gepflegt. Sie können den Quelltext für ein bestimmtes Kapitel finden, indem Sie zum relevanten Tag navigieren. Der Code für Kapitel 10 zum Beispiel ist unter http://github.com/padraic/ZFBlog/tree/Chapter-10 zu finden. Die Entscheidung zugunsten git fiel mir dank Github leicht. Falls Sie dieses Versionskontrollsystem nicht kennen: Github bietet eine Downloadoption für alle Tags und Zweige (Branches). Hier nun ein kurzer Überblick, wie man den Quelltext für ein Kapitel über git bezieht.

Um den Quelltext aus dem Repository zu holen, sollten Sie es klonen. Klonen entspricht einem Checkout in Subversion. Um das Repository in das Verzeichnis ./zfblog zu klonen, verwenden Sie auf der Konsole den folgenden Befehl:

git clone git://github.com/padraic/ZFBlog.git zfblog

Das Klonen sollte sehr rasch vonstatten gehen (git ist schnell!).

Initialized empty Git repository in /home/padraic/projects/misc/zfblog/.git/
remote: Counting objects: 120, done.
remote: Compressing objects: 100% (94/94), done.
remote: Total 120 (delta 31), reused 0 (delta 0)
Receiving objects: 100% (120/120), 19.63 KiB, done.
Resolving deltas: 100% (31/31), done.

Standardmäßig wird Ihr Zweig auf "master" gesetzt. Im Gegensatz zu Subversion verwendet git nicht das typische Trunk/Branches/Tags-Modell, aber der "master"-Zweig kommt dem Konzept des Trunk bei vielen Projekten am nächsten. Der gesamte Inhalt des Verzeichnisses ./zfblog wird aus diesem Zweig kommen. Da Sie vermutlich eher daran interessiert sind, den Code kapitelweise zu verwenden als die vollendete Kapitel-X-Version, werden Sie die passendste getaggte Version beziehen wollen. Eine Liste aller verfügbaren Tags erhalten Sie mit:

git tag -l

Mit git auf einen Tag oder Zweig zuzugreifen, ist im Vergleich zu Subversion ungewohnt. Zunächst einmal gibt es keinen physischen Pfad! Stattdessen machen Sie ein "Checkout" von einem Zweig oder Tag und git aktualisiert damit das aktuelle Arbeitsverzeichnis. Sie können ein Checkout von jedem Zweig oder Tag machen, inklusive einer jederzeitigen Rückkehr zum Master. Das Zusammenführen von Entwicklungszweigen funktioniert ähnlich - es müssen dafür nicht alle Pfade physisch vorhanden sein. Das mag zuerst sehr seltsam wirken, aber man gewöhnt sich bald daran. Sie werden auch bald feststellen, dass das Anlegen von Entwicklungszweigen in git extrem "billig" und einfach ist. Um ein Checkout des Tags für Kapitel 10 zu machen, wenden Sie den folgenden Befehl an:

git checkout -b Chapter-10

Ihr Arbeitsverzeichnis wurde nun auf den Stand des Tags gebracht und Sie bekommen die folgende Nachricht:

Switched to a new branch "Chapter-10"

Jetzt können Sie den Quelltext für das entsprechende Kapitel sehen, ohne dass zukünftige (auf den Master angewendete) Änderungen in den Weg kommen. Genauso können Sie zu jedem anderen Tag oder Zweig wechseln. Die Option -b wird eigentlich nur beim ersten Checkout eines neuen Zweigs oder Tags benötigt - damit wird ein lokaler Entwicklungszweig erzeugt, der mittels des Repository aktualisiert werden kann.

Falls Sie die Orientierung verlieren und nicht mehr wissen, in welchem Zweig oder Tag Sie sich gerade befinden (das ist ohne physische Pfade leicht möglich!), geben Sie diesen Befehl ein:

git branch

Ohne Argumente wird eine Liste aller existierenden Zweige und Tags erzeugt, wobei dem aktuellen ein Stern vorangestellt wird.

* Chapter-10
  master

Als abschließende Bemerkung: folgende Kapitel können Konfigurationsdateien als .example-Dateien beigefügt haben - das deutet an, dass sie kopiert und editiert werden sollten, bevor sie verwendet werden. Das wird der Fall sein, wenn Optionen private API-Schlüssel oder ähnliche Informationen enthalten.

1.3. Ich, Ich, Ich!

Dieses Buch handelt nicht von mir, aber dennoch bin ich als Autor sozusagen unvermeidbar!

Ich bin nun seit über 10 Jahren PHP-Entwickler mit Erfahrung in anderen Programmiersprachen einschließlich Java, Ruby und C/C++. Viele Jahre davon unterhalte ich schon einen Blog unter http://blog.astrumfutura.com, auf dem ich jeden Monat Stunden damit zubringe, den Lesern meine Gedanken und Meinungen in Form von Artikeln und Tutorials näher zu bringen und meine Interessensgebiete zu erleuchten. Ich lebe in Irland und werde das hoffentlich immer tun. Ich liebe diese winzige, kleine Insel über alles.

Ich bin bekannt als eine eigenwillige Person mit Sinn für Humor. Ich werde in diesem Buch immer wieder Witze reißen und Sie sollten - ohne Rücksicht auf ihre Qualität - lächeln oder für ein paar Sekunden kichern, nachdem Sie sie gelesen haben. Lassen Sie es geschehen, ich weiß, Sie wollen es... In der Vergangenheit war ich bezüglich einiger Zend-Framework-Features und -Ansichten sehr kritisch und werde das auch weiterhin sein. Sie können davon ausgehen, dass ich diesen Meinungen in diesem Buch (innerhalb gewisser Grenzen) Luft machen werde, da ich denke, dass sie bestimmte, für Entwickler interessante Einzelheiten veranschaulichen und Sie als Entwickler angemessen und begründet warnen, wenn Sie sich in gefährliches Fahrwasser begeben. Der Titel dieses Buches ist nicht "Blindly Praising The Zend Framework". Jedes Framework hat seine Makel, ganz gleich, was seine Entwickler sagen. Zu wissen, was diese Makel sind und wie man sie umgehen kann, ist wertvolles Wissen.

Zuletzt trage ich (trotz all meiner Meckerei) selbst zum Zend Framework bei. Ich habe bei Zend_View, Zend_Oauth, Zend_Crypt, Zend_Feed_Reader, Zend_Feed_Pubsubhubbub, Zend_Service_Yadis und Zend_Captcha_Recaptcha mitgewirkt oder sie eingebracht; wahrscheinlich habe ich noch mehr vorgeschlagen, bei denen ich noch nicht dazu gekommen bin, etwas zu tun. Das sollte heißen, dass ich vermutlich weiß, was ich tue - nur für den Fall, dass Sie dachten, ich wäre ein Spinner oder etwas ähnliches. Falls ich einen Fehler mache, lassen Sie es mich wissen und ich werde es korrigieren!

1.4. Zu dieser Übersetzung

Bei diesem Werk, das Sie gerade lesen, handelt es sich um die deutsche Übersetzung des Buches "Zend Framework: Surviving The Deep End", das ursprünglich von Pádraic Brady auf Englisch verfasst wurde.

Diese Übersetzung stammt von mir, Matthias Zeis - und nur in diesem Kapitel bezieht sich das "ich" tatsächlich auf meine Person. Im Rest des Buches spricht Pádraic durch mich zu Ihnen. Ich bin dankbar, dass ich diese Aufgabe übernehmen durfte und hoffe, dass ich Pádraics Wortwitz einigermaßen ins Deutsche hinüberretten konnte. Ich habe mich bei englischen Fachbegriffen an allgemein übliche Übersetzungen (sofern vorhanden) oder an Formulierungen aus der deutschsprachigen Referenz gehalten. Da Englisch aber nun einmal die Sprache der Programmierer und manchmal kein deutsprachiges Äquivalent vorhanden ist, werden Sie immer wieder auf Originalbegriffe treffen.

Meine erste Begegnung mit PHP reicht in das Jahr 2002 zurück. Seitdem entwickle ich Webanwendungen auf der Client- sowie der Server-Seite und habe dies nach meinem Studienabschluss im Jänner 2009 zu meinem Hauptberuf gemacht. Ich staune über die Entwicklungen, welche die gesamte Community in den letzten Jahren durchgemacht hat, bin gespannt auf die Zukunft und möchte sie ein klein wenig mitgestalten. Ich lebe in Wien, der Hauptstadt von Österreich, und kann jedem von Ihnen nur empfehlen, der Stadt an der schönen blauen Donau einmal einen Besuch abzustatten.

Ich möchte die Blogosphäre in nicht allzu ferner Zukunft mit einem weiteren Weblog beglücken. Die potentiellen Themen umfassen vieles, was Webentwickler täglich an Herausforderungen erwartet: PHP-Projekte wie (unvermeidbar!) Zend Framework und das darauf basierende e-Commerce-System Magento, die Gestaltung von Websites als optimales Erlebnis für die Besucher, aber auch übergeordnete Thematiken wie Entwicklungsprozesse, Deployment oder Projekt-Management. Bis dahin können Sie mir gerne auf meiner Website https://www.matthias-zeis.com oder bei Twitter unter http://www.twitter.com/mzeis einen Besuch abstatten.

Falls Sie Kommentare, Bemerkungen, Vorschläge oder Ideen zur Verbesserung dieser Übersetzung haben, zögern Sie bitte nicht, mich unter matthias.zeis _at_ gmail.com zu kontaktieren. Ich habe zum ersten Mal ein komplettes Buch übersetzt und kann mit Ihrer Hilfe sicher viel dazulernen.

Nun bleibt mir nur noch übrig, Ihnen viel Spaß bei der Lektüre dieses Buches zu wünschen. Padráic möchte auch noch ein paar Worte an Sie richten!

1.5. Sie, Sie, Sie!

Das Konzept des Buches wirkt vielleicht etwas ungewohnt. Es ist um eine Anwendung herum aufgebaut, die Komponenten des Zend Framework werden nicht jede für sich aufgeschlüsselt vorgestellt und Wissen wird vermittelt, indem man beim Erstellen der Anwendung auf Probleme trifft. Dieser Ansatz ist sehr praxisnah und wurde so gewählt, um sich mehr auf das Gesamtbild der Anwendung zu konzentrieren als auf jede Einzelheit der Komponenten-APIs. Diese werden vom Referenzhandbuch mehr als ausreichend abgedeckt.

Sie sind dazu aufgerufen zu experimentieren, während Sie dieses Buch lesen. Es gibt nicht den einen richtigen Weg, um eine Funktionalität einer Anwendung zu entwickeln, also probieren Sie ruhig, Probleme auf Ihre eigene Art zu lösen. So werden Sie mehr lernen.

Möchten Sie etwas loswerden, dann können Sie auf der offiziellen Website zum Buch (http://www.survivethedeepend.com) nicht nur alle Kapitel nachlesen, Sie können sich dort sogar beschweren, da wir in der Online-Version einen Kommentar-Bereich bereitstellen und ein Forum existiert, um anderen Lesern (und mir, wie ich annehme) Fragen zu stellen. Unter http://www.twitter.com/padraicb können Sie mir auch bei Twitter ein paar Zeilen hinterlassen.

Bringen Sie nun Ihre Sitze in eine aufrechte Position, klappen Sie die Tische hoch und entspannen Sie sich. Dann blättern Sie um, um mit Kapitel 2 fortzufahren.