Build-Systeme sind ja schon eine wirklich praktische Sache. Bisher habe ich zur Erledigung solcher Sachen eine Kombination aus PHP, Shell Scripten und GNU make verwendet. Problem an dieser Kombination: Shell Scripte und make sind nicht wirklich plattformübergreifend einsetz- oder gar verfügbar. Nachdem ich für Propel ohnehin schon Phing installieren musste, habe ich mir dieses System mal näher angesehen. Phing ist von Apache ANT inspiriert und verwendet eine ähnliche Syntax für die Build-Scripte, basierend auf XML Dateien.

Mein Wunsch war es ein Script zu schreiben, welches ein Gerüst für eine Anwendung erstellt. Für dieses Gerüst gibt es eine Vorlage, die kopiert werden muss. Zusätzlich müssen einzelne Verzeichnis- und Dateinamen umbenannt werden, sowie Inhalte diverser Dateien geändert werden.

Ausschnitt aus dem build.xml für Apache ANT (Die Unterschiede zu Phing finden sich in erster Linie beim Filterchain):

Mit Phing bin ich jedoch nicht besonders weit gekommen - im Gegenteil hat es mich schnell angefangen zu ärgern. So habe ich den Eindruck gewonnen, das nicht alle in der Dokumentation beschriebenen Kommandos so arbeiten, wie sie sollten. Ich habe vergeblich versucht leere Verzeichnisse, die meine Vorlage nunmal enthält, mittels des Copy-Tasks zu kopieren. Trotz dem Setzen des Flags 'includeemptydirs' geht es nicht. Nachdem ich den Quellcode von Phing ge-grep-t habe, habe ich allerdings auch den Eindruck gewonnen, dass dieses Feature nicht vollständig implementiert ist. Dann jedoch frage ich mich, warum es in die Dokumentation aufgenommen wurde?

Ausserdem arbeitet das Umbenennen von Verzeichnissen und Dateien nicht so, wie ich mir das Vorstelle. Dafür gibt es den Task 'mapper'. Verwende ich ihn in Verbindung mit Copy bzw. Move, werden allerdings nur noch Dateien kopiert, in denen das Pattern des mapper-Tasks auftaucht. Ich weiss nicht ob die Entwickler von Phing hier das bewusst so entwickelt haben...? ANT verhält sich jedenfalls anders als Phing und ich kann das erreichen, was ich eigentlich möchte: nämlich alle Dateien kopieren und dabei zusätzlich alle Dateien und Verzeichnis umbenennen, die auf ein bestimmtes Suchmuster passen.

Ich weiss nicht, wie hoch der Verbreitungsgrad von Phing in PHP Projekten ist - neben Propel wird es noch in den PHP Frameworks BinaryCloud und Symfony eingesetzt. Bis auf die Dokumentation auf der Projektseite von Phing, habe ich nicht wirklich viele brauchbare Informationen gefunden, die einem Einsteiger bei Problemlösungen helfen könen. Tutorials sucht man vergeblich - wurde Phing schon in einem PHP Buch behandelt? Leider scheint auch auf der Mailingliste sehr wenig zu passieren. So denke ich, dass Phing, wenn es eine alternative zu ANT zumindest für PHP Projekte werden soll, noch einen weiten Weg vor sich hat.

Nach Phing habe ich mir also dann das Original angesehen - Apache ANT. ANT ist in Java entwickelt und ursprünglich wohl auch in erster Linie für Java Entwickler gedacht. Somit wird also beim Einsatz auch ein JRE benötigt. Da Phing wie gesagt von ANT 'inspiriert' ist, funktioniert meine Build-Konfigurationen ohne grössere Änderungen auch mit ANT. Und siehe da: Mein Build-Script funktioniert so, wie ich es mir vorgestellt habe. Anders als mit Phing werden leere Verzeichnisse kopiert, das Umbenennen von Dateien wird genauso wie das Ändern von Dateiinhalten nebenbei erledigt. Ich denke, dass sich Phing damit für mich erstmal erledigt hat und ich lieber ANT verwenden werde. Vielleicht ist ein Script wie ich es mir vorstelle auch mit Phing möglich - ich habe jedenfalls verschiedenste Varianten ausprobiert, mir ist es nicht gelungen eines zu entwickeln.

Nebenbei sind die Vorteile von ANT: Es wird vielen Java Projekten eingesetzt, die Community ist sehr gross und es gibt viele Dokumentationen und Tutorials im Internet zu finden, sowie auch Bücher zu kaufen.

Nun benötige ich Phing natürlich dennoch für Propel. Da Propel eigene Erweiterungen für Phing mitbringt, kann man hier nicht einfach ANT anstelle von Phing einsetzen. Wie man Phing von ANT aus starten kann, beschreibt Roman Roan in seinem Blog - 'Running Phing with ANT'.

Weitere empfehlenswerte Artikel:

• Improve Your Build Process with Ant - erschienen im O'Reilly PHP Devcenter
• Apache ANT - Manual
• ANT Tutorial

Ich verwende schon seit einiger Zeit Creole als Datenbankabstraktionslayer und bin damit super zufrieden. Creole dient auch als untere Schicht für das Projekt Propel.

Bei Propel handelt es sich um eine Implementierung des Entwurfsmusters 'Data Access Obects'. Ziel ist es Datenbankzugriffe von der Anwendung zu entkoppeln. Beim Einsatz von DAO werden Zugriffe per SQL auf eine Datenbank innerhalb einer Applikation vermieden. SQL wird nur noch innerhalb der DAO Bibliotheken verwendet, der Entwickler einer Anwendung basierend auf Data Access Objects greif nur noch auf die bereitgestellten Objekte zu.

Eigentlich habe ich Propel in meiner Unwissenheit immer als 'bloated' betrachtet. Es ist eine recht umfangreiche Bibliothek und benötigt das PHP Build System Phing. Die Abhängigkeiten arten schon etwas aus, allerdings lassen sich alle benötigten Bibliotheken bequem über PEAR installieren:

Die Runtime Bibliotheken werden nur auf einem System benötigt, auf dem das Propel-basierte Projekt später laufen soll. Umgekehrt müssen auch die Generator Bibliotheken nur auf einem System installiert werden, auf dem die Klassen generiert werden.

Der Einsatz von Propel gestaltet sich einfacher als ich dachte. Eine Datenbank wird per XML beschrieben. Es können auch bestehende Datenbanken gelesen werden und die XML Struktur automatisch generiert werden. Das habe ich allerdings noch nicht ausprobiert. Das Erstellen der XML Datei für die Datenbankstruktur ist relativ einfach und geht schnell von der Hand. Es werden Tabellen und Spalten definiert und Abhängigkeiten über Fremdschlüssel.

Aus einer fertigen XML Datenbankstruktur wird dann zum einen ein SQL-File zum Einspielen in die Datenbank generiert, zum anderen werden alle PHP Klassen erstellt, die zum Zugriff auf die Daten Objekte benötigt werden. Hier kommt das Build System Phing zum Einsatz. Beim Einsatz von Propel erspart man sich das (oftmals auch durchaus nervige) Schreiben von SQL Anweisungen - das Einfügen eines neuen Datensatzes in die Datenbank gestaltet sich dann so einfach wie z.B.:

Beim Speichern einer Ausstellung wird im obigen Beispiel automatisch zunächst eine neue Adresse angelegt und der Primary-Key des Datensatzes als Adress-ID in der Ausstellung übernommen. Auch Abfragen der Datenbank gestalten sich äusserst einfach.

Propel benötigt mindestens MySQL der Version 4.0.x. Es läuft allerdings auch mit 4.1.x sowie - wie bei mir - mit den Versionen 5.0.x. Allerdings werden neue Features, insbesondere der Version 5 nicht unterstützt. Ausserdem können alle Datenbanken eingesetzt werden, die Creole unterstützt. Neben dem schon erwähnten MySQL wären das PostgreSQL, MS SQL Server und SQLite.

Resin von Caucho ist ein Java Application Server mit PHP Unterstützung. PHP Code wird intern in Byte Code übersetzt und soll so bis zu sechs mal schneller sein als das entsprechende Programm unter Apache mit mod_php. Benchmarks, die diese Behauptung untermauern, sucht man leider vergebens.

Im Moment sind die Informationen noch recht spärlich gesäht. Hier kann man sich zumindest einiges rausziehen: so wird wohl PHP5 unterützt - allerdings noch nicht der komplette Sprachumfang.

Neben der Geschwindigkeit soll ein Vorteil der sein, dass man sehr einfach in Java geschriebene Module unter PHP ansprechen kann.

Klingt interessant - auch wenn die Informationen doch recht dünn sind. Sollte man mal im Auge behalten.

1. Named Parameters wie man sie z.b. von Perl kennt, wird es nicht geben. Man wird also weiterhin ein assoziatives Array als Parameter übergeben müssen, wenn man bei der Parameterübergabe mehr Flexibilität wünscht.
2. Dafür wird es eine Art GOTO geben: Die Funktion break soll so erweitert werden, dass man nicht nur wie bisher aus einer oder mehreren Ebenen ausbrechen kann, sondern dass man auch ein Label definieren kann, zu dem ein Sprung über den break-Befehl möglich sein soll. Ich bin ehrlich gesagt geschockt: ich denke dass dies dazu führen wird, dass sich mancher Programmierer nicht mehr die Mühe machen wird, seinen Code sauber zu strukturieren und dass die Lesbarkeit des Codes darunter leiden wird. Ausserdem denke ich dass die Ästhetik von PHP - die ohnehin an manchen Stellen sehr unschön ist - durch die Einführung von Labels weiter leidet.
3. Es gibt keine klare Aussage zum Thema Name Spaces bzw. wirkt der im Protokoll beschriebene Ansatz auf mich etwas lustlos formuliert (vermurkst). Ich gehe mal davon aus, dass auch bei PHP 6 am Ende Name Spaces unter den Tisch fallen werden.
4. Ich würde mir einen with-Befehl wünschen, wie man ihn z.b. von Pascal oder Javascript her kennt.

Ganz so ist es natürlich nicht - aber die Arbeiten daran haben scheinbar begonnen. Der Grund für einen derartigen Versionssprung wird sein, dass PHP 6 endlich Unicode fähig sein wird. Hierfür wird wohl die ICU Bibliothek von IBM verwendung finden. Dabei soll die Unicode Unterstützung völlig transparent im Hintergrund ablaufen. D.h. das ab PHP 6 alle Stringfunktionen wie substr, str_replace usw. unicode-fähig sein werden.

Angedacht ist wohl auch das Loswerden einiger Funktionen, die bereits seit PHP3 und 4 als veraltet markiert sind oder auch das entgültige Entfernen der Option 'register_globals'.

Ich persönlich würde mir wünschen, dass dann vielleicht auch wieder Namespaces ein Thema werden - ist das völlig vom Tisch? Über die Unterstützung von Namespaces in PHP hört und liest man leider gar nichts mehr, nachdem diese ja in Version 5 dann leider doch rausgeflogen sind.

Ich bin kürzlich wieder auf den VIM als Entwicklungsumgebung für PHP umgestiegen, nachdem ich ja sehr lange Zeit mit Jedit entwickelt habe und damit auch im Grossen und Ganzen sehr zufrieden war.

Das Problem mit jedit war höchstens, dass es als Java Applikation auf meinem Powerbook doch manchmal etwas träge war, vor allem wenn ich gleichzeitig MP3s gehört habe. Also musste doch wieder ein schnellerer Editor her und natürlich wieder einer, der auf allen Plattformen verfügbar ist und nachdem ich ohnehin hin und wieder dem VIM nachgetrauert habe, bin ich ohne lang zu überlegen wieder umgestiegen.

Dafür habe ich mir das Buch 'vim ge-packt' von Reinhard Wobst aus dem mitp-Verlag gekauft um mal etwas tiefer in den VIM einzusteigen. Generell hat man ja bei Büchern über den VI nicht viel auswahl, aber das o.g. Buch eignet sich auch glücklicherweise wirklich hervorragend für den tieferen Einstieg. Es handelt sich um eine kompakte Referenz, die die wichtigsten Themen zum Umgang mit dem VI behandelt. Sehr hilfreich sind auch die vielen weiterführenden Hinweise auf die in VIM integrierte Hilfe.

Natürlich hatte ich wenig Zeit (und Lust) mir eine eignene Konfiguration für den VIM zu basteln und so habe mal im Internet nach brauchbarem gestöbert. Dabei bin ich auf die Serie 'Comfortable PHP editing with VIM' im Weblog von Tobias Schlitt gestossen. Netterweise bietet er auch gleich seine .vimrc zum Download an, mit der es sich wirklich komfortabel unter dem VIM entwickeln lässt. Die Serie umfasst (derzeit) drei Teile, die ich hier verlinkt habe.

• Comfortable PHP editing with VIM - Teil 1
• Comfortable PHP editing with VIM - Teil 2
• Comfortable PHP editing with VIM - Teil 3

Zum Abschluss möchte ich noch auf das Script Archiv auf der Homepage des VIM verweisen, das 100e Erweiterungen bereitstellt, sodass man sich eine äusserst mächtige Entwicklungsumgebung bauen kann, die eigentlich keine Wünsche mehr offen lässt.

Wie der Name schon andeutet, soll phpa ein Ersatz für den interaktiven Modus von PHP 'php -a' sein und ist selbst auch in PHP geschrieben. Dank der readline Bibliothek erhält man eine vollwertige Shell mit editierbarer Befehlseingabe, einer History der eingegebenen Befehle sowie automatische Vervollständigung von PHP Befehlen über die Tabulator-Taste - wie man es eben von anderen Tools für die Console gewohnt ist.

Nett ist dabei, dass man sofort das Ergebnis sehen kann, von dem, was man über die Shell 'programmiert' hat, ohne dabei die Shell verlassen zu müssen. Man kann dabei auch komplexere
Sachen entwickeln z.b. eigene Funktionen schreiben und austesten.

Den einzigen Nachteil, den ich bisher sehen kann, ist dass man sich PHP höchstwahrscheinlich selbst compilieren muss, da die readline Bibliothek nicht zu den Standardkomponenten einer 'normalen' PHP Installation zählt. Ausserdem funktioniert die readline Erweiterung für PHP so weit ich informiert bin nicht unter Windows - aber damit kann ich leben .

[update]

Natürlich gibt es auch für phpa keine Möglichkeit einen 'Fatal Error' in PHP abzufangen, was wirklich ärgerlich ist, denn schon die falsche Schreibweise eines Befehls löst einen 'Fatal Error' in PHP aus und erzwingt so auch das Beenden von phpa. Meiner Ansicht nach ist das ein echtes Manko von PHP, dass ein 'Fatal Error' zwar über 'set_error_handler' ausgewertet werden kann, der Programmablauf danach aber von der Zend Engine zwingend abgebrochen wird.

Interessant ist in diesem Zusammenhang auch der Vergleich von Funktionen wie preg_replace und str_replace. Erstere ist zwar sehr viel flexibler, kostet aber bei der Ausführung auch sehr viel mehr Zeit. Oft kann man Scripten auf diese Weise gut optimieren, indem man ein preg_replace durch einen Code-Block mit den Standard String-Funktionen von PHP wie str_replace, substr, etc. ersetzt. Das ist dann zwar mehr Code, kann aber am Ende u.U. um einiges schneller sein als die Lösung mittels preg_replace.

Xdebug ist derzeit noch beta, läuft aber für meine Verhältnisse äußerst stabil. Die Installation gestaltet sich relativ einfach. Entweder man installiert das ganze über PECL, oder man holt sich den Quellcode von xdebug und PHP und compiliert sich xdebug selbst als PHP modul. Auf der Web Seite von xdebug finden sich ausführliche Informationen zur Installation und Konfiguration des Moduls.

Wenn jemand eine Lösung zum Visualisieren der cachegrind Dateien für Mac OS X kennt, der möge sich bitte melden - denn die fehlt mir hier leider noch .