1.2 PEAR – ein Überblick 
Das PEAR-Projekt wurde 1999 von Stig Bakken ins Leben gerufen. Die Abkürzung PEAR steht für »PHP Extension and Application Repository« und stellt eine umfangreiche Open-Source-Bibliothek dar.
Die primären Ziele des PEAR-Projekts sind:
- Ein System für die Verteilung und Betreuung von Paketen zur Verfügung zu stellen
Des Weiteren gibt es noch einige kleinere Spin-Off-Projekte wie zum Beispiel PECL.
Das PEAR-Projekt besteht zurzeit (Mai 2005) aus 420 verschiedenen Paketen, die von 215 Entwicklern betreut werden. [Die aktuellen Zahlen finden Sie unter http://pear.php.net/package-stats.php ]
In diesem Kapitel finden Sie einige Hinweise zum Umgang mit PEAR-Paketen, die Ihnen das Leben erleichtern sollen. Ich möchte Sie bitten, dieses Kapitel aufmerksam zu lesen, weil der eine oder andere Hinweis Ihnen die Arbeit sicher deutlich vereinfachen kann.
1.2.1 Die PEAR-Website
Das PEAR-Projekt verfügt über eine eigene Website, die die URL http: //pear.php.net hat. Hier finden Sie alles, was das Projekt betrifft.
Wie Sie in Abbildung 1.1 sehen, ist die Website komplett in Englisch. Zwar gibt es für einzelne Pakete auch eine deutsche Dokumentation, aber das ist doch eher selten. Auf der linken Seite finden Sie die Hauptnavigation, und auf der rechten Seite finden Sie in einer Liste die aktuellen Neuerungen und Veröffentlichungen neuer Programmversionen.
Suchen Sie ein Paket zu einem bestimmten Themenbereich oder ein Paket, das bestimmte Funktionalitäten unterstützt, können Sie eine Stichwortsuche im Kopf der Seite durchführen, oder Sie klicken in der linken Navigation auf den Punkt List Packages. Nach einem Klick auf diesen Punkt erhalten Sie die Darstellung aus Abbildung 1.2.
Abbildung 1.1 Die Website des PEAR-Projekts
Abbildung 1.2 Kategorien des PEAR-Projekts
Sie finden hier verschiedene Kategorien. Alle Pakete sind in diese Kategorien eingeteilt, und dieses Buch orientiert sich auch an diesen Kategorien. Da das Projekt sehr dynamisch wächst, kann es schnell passieren, dass zu viele Pakete in einer Kategorie sind. In diesem Fall werden die Kategorien aufgeteilt. Auch kann es passieren, dass ein neues Paket keiner Kategorie zugeordnet werden kann und somit eine neue Kategorie dafür angelegt wird.
Klicken Sie auf eine der Kategorien, erhalten Sie eine Liste mit den Paketen, die zu einer Kategorie gehören. Einige der Pakete können Sie auch in der Übersicht direkt anklicken.
Die Homepage eines Pakets ist eine wichtige Anlaufstelle für Sie. Hier finden Sie alle Informationen rund um das Paket. Die Homepage des Pakets Text_Wiki sehen Sie in Abbildung 1.3.
Abbildung 1.3 Homepage eines Pakets
Einige Menüpunkte möchte ich Ihnen kurz erläutern. Unter Summary bzw. Description ist kurz zusammengefasst, was das Paket leistet. Wichtig ist der Punkt License. Hier finden Sie die Information, unter welcher Lizenz das Paket bereitgestellt wird. Gerade, wenn Sie ein Paket kommerziell nutzen möchten, ist das nicht ganz unwichtig, da in der Lizenz die Nutzungsbedingungen vermerkt sind, unter der Sie das Paket einsetzen dürfen. Der Name der Lizenz ist jeweils mit dem Text der Lizenz verlinkt.
Der Punkt Current Release gibt Ihnen die Information, welches die aktuelle Version des Pakets ist. Da dieses Buch natürlich immer nur bis zu einem gewissen Versionsstand aktuell sein kann, sollten Sie immer einen Blick auf das Changelog werfen. Bei der Erläuterung jedes Pakets in diesem Buch finden Sie die Information, auf welche Version sich der Text bezieht. Im Changelog finden Sie die Informationen, was sich in welcher Version geändert hat. Somit sind Sie immer auf dem aktuellen Stand.
In fast allen Fällen handelt es sich bei den Änderungen um Erweiterungen oder Fehlerbereinigungen. Allerdings werden Sie auch hier und da einen Hinweis finden wie »Breaks BC«. BC steht für »backwards compatibility« und bedeutet in diesem Zusammenhang, dass es Änderungen in dem Paket gegeben hat, die dafür sorgen, dass die neue Version nicht mehr zu 100 % kompatibel mit der Vorgängerversion ist. Teilweise wurden Methoden oder Klassen einfach nur umbenannt, manchmal passiert es aber auch, dass bestimmte Funktionalitäten komplett wegfallen.
Falls Sie weitergehende Informationen benötigen, gibt es verschiedene Ansätze, die Ihnen weiterhelfen können. Auf den Menüpunkt Documentation, den Sie in der oberen Navigation finden, gehe ich gleich ein. Zuerst sollten Sie schauen, ob Sie rechts unten, unter More Information, einen Link zu einer External Package Homepage finden. Viele Pakete verfügen über eine externe Homepage, die in den meisten Fällen deutlich hilfreicher ist als die Dokumentation, die auf der PEAR-Website zu finden ist. Sollten Sie sich noch nicht mit einem Paket auskennen, ist ein Blick auf die Trackbacks sehr hilfreich, die Sie oben in der Navigation finden. Hier sind externe Anleitungen zu finden, die das Paket erläutern. Das kann sehr hilfreich sein, um einen Zugang zu dem Paket zu finden.
Klicken Sie den Menüpunkt Documentation an, erhalten Sie eine Seite wie die in Abbildung 1.4.
Die Seite gliedert sich in zwei Bereiche. Links finden Sie einen Link zur End-user Documentation. Diese Dokumentation für den Endanwender ist leider nicht immer vorhanden. Sollte das doch der Fall sein, erhalten Sie zuerst eine englische Dokumentation. Zwar existiert immer ein Link auf eine deutsche Version der Dokumentation, aber das heißt nicht, dass der Text, der dahinter zu finden ist, auch wirklich auf Deutsch ist.
Abbildung 1.4 Die Dokumentationsseite eines Pakets
Im rechten Bereich finden Sie die API documentation. Für jede Version, die veröffentlicht wurde, ist hier ein Link zu finden. API ist die Abkürzung für Applications Programmers Interface [Oder wahlweise »Application Programming Interface« bzw. »Application Program Interface« ] und bezeichnet die Schnittstelle, die hier für Programmierer erläutert wird. Es handelt sich dabei um eine automatisch generierte Dokumentation. phpDocumentor, das Programm, das die Dokumentation erstellt, erkennt automatisch Abhängigkeiten von Dateien und Klassen. Allerdings kann es nicht erkennen, was die Methoden machen oder wozu sie genutzt werden sollen. Daher muss der Programmierer die eigentliche Erläuterung der Funktionalität selbst ergänzen. Somit fällt der Umfang der Beschreibungen sehr unterschiedlich aus.
Bitte wundern Sie sich nicht, dass einige der Links »ins Leere« laufen und eine Fehlermeldung generieren. Das liegt daran, dass nicht immer eine neue Dokumentation generiert wird. Meist ist das der Fall, wenn beispielsweise ein Release Candidate, also eine Version, die kurz vor der Fertigstellung steht, veröffentlicht wird. Dafür wird dann eine Dokumentation erstellt. Die nachfolgenden Versionen weisen dann nur Fehlerkorrekturen auf, so dass keine neue Dokumentation notwendig ist.
Die API-Dokumentation zu nutzen ist teilweise ein wenig gewöhnungsbedürftig, da die meisten Pakete aus relativ vielen Dateien bestehen. Lassen Sie sich von der Vielzahl der Dateien nicht irritieren, und versuchen Sie zu erkennen, welche Klasse welche andere Klasse beinhaltet. Dann finden Sie recht schnell heraus, welche Methoden und Funktionalitäten vorhanden sind.
Der letzte Punkt, der Ihnen weiterhelfen kann, befindet sich auf der eigentlichen Homepage des Pakets. Hier können Sie das Paket mit dem Link, der sich unter Current Release befindet, direkt herunterladen und auf dem Client öffnen. Zwar handelt es sich hierbei um das gleiche Paket, das auch auf dem Server installiert wird, aber in dem Archiv befinden sich auch Beispiel-Dateien oder auch Readme-Dateien, die die Nutzung erläutern. Ein weiterer Vorteil ist, dass Sie die Klassen-Dateien auch in Ihrer Entwicklungsumgebung öffnen können. Nutzen Sie beispielsweise das Zend Studio als Entwicklungsumgebung, dann werden die Klassen und Methoden direkt in die Komplettierungsdatenbank übernommen. Damit müssen Sie die Befehle dann nicht komplett tippen, sondern können sie mit einem Mausklick oder der (Enter)-Taste übernehmen.
1.2.2 Auswahl von Paketen
In einigen Fällen gibt es mehrere Pakete, die Ähnliches leisten. Teilweise stellt sich auch die Frage, ob Sie überhaupt ein PEAR-Paket nutzen sollen, wenn Sie ein neues Projekt beginnen. Immerhin hängt Ihr Projekt dann von fremdem Code ab.
Die Antwort auf die Frage ist nicht einfach. Ich persönlich versuche PEAR-Pakete immer anhand bestimmter Kriterien zu beurteilen.
Zuerst stellt sich die Frage, wie viele Veröffentlichungen es in diesem Projekt bereits gab und ob diese in regelmäßigen Zeitabständen erfolgten. Sie werden feststellen, dass es einige Projekte gibt, bei denen der Entwickler in der Anfangszeit sehr euphorisch war und alle paar Tage eine neue Version veröffentlicht hat, aber sich danach für Monate oder Jahre nicht um das Projekt gekümmert hat. Das sollte Sie stutzig machen.
Des Weiteren sollten Sie einmal den Link Bugs auf der Homepage des Pakets anklicken. Hier werden offene Probleme aufgelistet, die es bei der Nutzung des Pakets gibt.
Sollten Sie hier Fehler finden, die schon vor Monaten gemeldet wurden, aber noch nicht bearbeitet worden sind, ist das nicht unbedingt ein Problem. Sie sollten aber noch ein wenig weiter nachforschen. Klicken Sie oben rechts auf den Status All. Dann sehen Sie auch alle Probleme, die bereits behoben wurden. Wenn Sie hier eine große Liste mit gelösten Problemen sehen und nur einige wenige Bugs noch nicht gelöst wurden, dann haben Sie eine gute Chance, dass das Paket gut betreut wird. In Abbildung 1.5 sehen Sie einen Auszug aus einer Bug-Liste. Hier sind nur zwei von 45 Fehlern noch nicht durch den Entwickler begutachtet bzw. gelöst worden.
Abbildung 1.5 Auszug aus einer Bug-Liste
Eine schöne, globale Statistik erhalten Sie auch unter der URL http:// pear.php.net/bugs/stats.php.
Des Weiteren empfehle ich Ihnen auch, dass Sie mit der Suchmaschine Ihres Vertrauens nach Erfahrungsberichten, Anleitungen oder anderen Quellen suchen, die sich mit dem Paket befassen.
