einige fragen zu pear

[msi]

hallo,

ein paar fragen zu pear ;-)
1. wie schätzt ihr das ein, wird pear in zukunft eine große rolle für php spielen?? oder ist das nur ein kleines Projekt von vielen die ähnlich sind.
2. ich kann in den php scripts einfach angeben require ("Auth/Auth.php"); nur wie wird angegeben, dass er nach diesem verzeichnis in /usr/share/pear (dort ist pear bei mir, debian standart) suchen soll? Also wo wird der "include path" festgelegt? Lässt er sich für eigene Projekte verändern, ist das guter php code stil, wenn man ihn benutzt um ein allgemeines header files verzeichnis festzulegen, oder sollte man bei einem config array bleiben??

danke, Markus

[mehlvogel]

Ich denke und hoffe (meine Meinung zu Pear hab ich hier glaub ich schon 1000 mal angegeben) das Pear sich durch setzt. Denn zumindest bei mir nicht. Große Bibliotheken, (also Klassen mit vielen Möglichkeiten) haben ein Problem: Wenn man nur einen Teil braucht, ist der Rest Resourcenverschwendung. Deswegen schreibe ich meine Klassen selbst und eigentlich für jedes Projekt neu, da ich immer andere Anforderungen habe und nur das einbaue was ich brauche, und das was überflüssig ist weglasse.

Schon alleine das es nicht auf jedem Server verfügbar ist, schränkt diese Untat für professionelle Programmierer schonmal ein. Zu Zweitens kann ich dir leider nicht viel sagen, da ich den Kram noch nicht angerührt habe und das auch in Zukunft lasse. (So, und jetzt bin ich auf Jana gespannt ;) )

[jwebworks]

Oder auf mich :D

Pear kann man mittlerweile auch im eigenen Webspace installieren
und es gibt sogar ein WebInterface zur Verwaltung.

Ich finde pear echt praktisch. Auch wenn viele Pakete einfach zu fett
sind, als dass man sie einfach so benutzen könnte.

Da ich für die meisten Sachen einfach keine Zeit habe, bestimmte
Dinge komplett neu zu entwickeln oder mir eigene Bibliotheken
auszubauen, nehme ich mir pear-Sachen her.

Ehrlicherweise muss ich aber sagen, dass ich mittlerweile ein eigenes
pear-repository habe, da ich kaum ein Paket unverändert verwende.
Ich brauche keine 1000-factory-Funktionen, mit denen ich eine Klasse
mit genauso vielen verschiedenen Datenbanken und Speicherformaten
ablegen kann.

Was mich noch stört ist, dass die meisten Klassen immer wieder eine eigene
Datenbankverbindung aufbauen wollen, anstatt einen DB-Object-Zeiger
anzunehmen und damit zu arbeiten. Das ist meist das erste, was angepasst
wird. Dann fliegen diese Factory-Dinger raus, weil ich meist eh nur eine Variante
davon benötige und der Quelltext nicht mehr Debugbar (ZendStudio ist ganz
nett) ist. Als Letztes schmeisse ich die Funktionen raus, die ich nicht benötige
und garantiert auch nicht benötigen werde. (Selbst wenn, kann ich sie immer
noch aus dem Original wieder einbauen)

Abschliessen muss ich sagen, dass ich immer wieder feststelle, dass dann
doch sehr viel Zeit in die Anpassung der pear-Sachen geflossen ist, aber sicher
weniger als wenn ich das Problem von Grund auf selbst hätte lösen müssen.

Pear: Praktisch, nimmt viel arbeit ab.
Pear: Eigener Code ist immer besser als Fremder.

cu, stop.h

[Gaert]

Hallo!

Ich finde Pear bietet einige nette Klassen, die einem (nicht mir) viel Arbeit abnehmen können.
Ich habe bisher lediglich eine Klasse aus Pear in einem Projekt eingesetzt... die MIME Mail Klasse - und ich war enttäuscht, da sie nicht korrekt funktioniert hat.
Ich verwende Pear allerdings als Inspiration für mein eigenes Repositoriy, welches ich ständig weiter ausbaue.
Das große Problem an Pear ist, war und wird auch weiterhin sein, dass der Kern des Projekts IMHO am Anfang nicht sehr gut geplant wurde, sondern wie in fast allen PHP Projekten einfach drauf los geschrieben wurde. Dies ist normalerweise kein Problem, da man ein Projekt ja während weiteren Entwicklung normalerweise einfach umschreiben kann, wenn man merkt, dass einige Sachen einfach unstimmig oder kompliziert sind.
Dies war bei Pear aber nicht mehr möglich, da man es von Anfang an als quasi Standard "verkauft" hat, und man den Programmierern, die darauf vertraut haben und damit ihre Applikationen geschrieben haben, (korrekterweise) nicht zumuten wollte ihre Projekte den neuen Befehlen anzupassen.
Ich will das Pear Team damit jetzt nicht schlecht machen... ein solches Monster Projekt hätte wohl nicht besser realisiert werden können, und Pear tut sicherlich gute Dienste, aber einige Sachen wie die bereits angesprochenen (Datenbank Connection wird nicht mitgenommen etc) sind echt ärgerlich.
Pear dient für mich, zusammen mit anderen PHP Frameworks als Inspiration für mein eigenes Web Application Repository (welches ich demnächst auch zum Download anbieten werde), welches einen anderen (besseren?) Weg geht als Pear.
Wie oben angesprochen merkt man meist erst während der Entwicklung einer solchen Klassensammlung wenn Sachen nicht so zusammenspielen wollen, wie sie sollen - dies ist auch der Grund, warum ich meine eigene Sammlung nun zu X-ten mal neugeschrieben habe (inklusive der Apps die ich damit schon realisiert hatte).

Genug gelabert... war viel OT dabei!

Abschließend ist zu sagen, dass Pear sicherlich nicht das Gelbe vom Ei ist, es aber auf jeden Fall praktisch und mit Sicherheit zukunftssicher ist...
Mein Tip: Einfach mal ausprobieren, ob man damit zurechtkommt.

Gruß,

Gaert

[jwebworks]

Gib mir bescheid, wenn Dein rep da ist. Evtl.
können wir ja (teilweise) zusammenlegen.

[Gaert]

Ich hab eh vor das ganze hier zur Diskussion zu stellen, wenns bereit für ein Release ist ;)