nicht angemeldet
Hi!
Hi,
»» ich habe nicht immer Zugriff auf die php.ini, um alle Pfade für Klassen einzutragen. Jedes Mal um die Erweiterung des include_path betteln will ich nicht, zudem wäre das auch gar nicht sinnvoll, weil es sehr, sehr viele Projekte gibt und der include_path bald nicht mehr überschaubar wäre.
include_path ist PHP_INI_ALL konfigurierbar.
Dann müßte ich dennoch gemeinsam genutzte Pfade wieder bei jedem Projekt per ini_set setzen, dann kann ich es auch gleich in der __autoload abhandeln.
»» Nun möchte ich aber zum einen Klassen aus PEAR benutzen, zum anderen während der Entwicklung gemeinsam benutzte Verzeichnisse über den include_path nutzen.
D.h. also, *nach* der Entwicklung wird die Pfadstruktur anders aussehen?
Ja, definitiv komplett anders, zumindest was Klassenverzeichnisse und das Applikationswurzelverzeichnis betrifft. Das alles wird auch schon in Konfig-Dateien berücksichtigt.
Das Entwicklungs-/Testsystem immer möglichst nahe am Produktivsystem zu halten, ist eigentlich immer sinnvoll.
Schon, aber ich habe da wenig Einfluß und muß mit dem Vorlieb nehmen, was ich vorfinde.
Hier könnten evtl. auch symbolische Links helfen, an einem Ort gelagerte Dateien für mehrere Projekte unter "individuellen" Pfaden bereitzustellen.
Damit kenne ich mich zu wenig aus. Kannst Du das deutlicher beschreiben, inwiefern man die nutzen kann?
»» So, wenn ich das richtig sehe, wird ein include 'irgendwas' (das aus Verzeichnis a, welches im include_path eingetragen ist); new irgendwas nicht irgendwas instantiieren, sondern __autoload aufrufen, was natürlich in b, c oder d irgendwas nicht findet, weil es ja in a ist. Also muß ich selbst in __autoload nach irgendwas in a suchen, und das möchte ich nicht. Es wäre mir recht, wenn das include 'irgendwas' aus a; new irgendwas erkennt bzw. zuerst den include_path durchgeht, daß die Klasse geladen ist bzw. aus a im inc_path geladen werden soll und nicht __autoload aufruft.
Hier hoffe ich nur, dass du in deinen Projekten strukturierter arbeitest, als du hier mit Sprache umgehst.
Sorry, kaum ein Wort verstanden von dem Kauderwelsch.
Eigentlich helfen die Antworten von Tom und Sven schon weiter bzw. beantworten die Frage, aber hier noch mal eine weniger "hingeschmierte" Beschreibung:
Ein oder mehrere Verzeichnisse, nennen wir eins davon A, enthalten gemeinsam von mehreren Projekten benutzte Klassen. Dieses sollte daher im inc_path aufgeführt sein. Projekte benutzen darüber hinaus projektspezifische Klassenverzeichnisse, nennen wir sie B und C.
Anforderung für die Entwicklung ist, daß zunächst A vom Parser durchsucht wird, wird er nicht fündig, überläßt er die weitere Suche der __autoload, die die projekteigenen Klassenverzeichnisse durchsucht.
Soweit die Entwicklungsumgebung. In der Produktivumgebung sollte es gerade umgekehrt laufen. Zunächst werden die projektspezifischen Verzeichnisse durchsucht, danach das oder die allgemeinen Klassenverzeichnisse. Der Sinn ist, daß Projekte zu einem bestimmten Zeitpunkt mit bestimmten Versionen von Klassen laufen, während es offenbleiben soll, die Klassen zu ändern, ohne daß dadurch ältere Projekte nicht mehr laufen. Dazu werden, sobald eine Applikation als fertig befunden wurde, die Klassen aus dem allgemeinen Klassenverzeichnis in der Entwicklungsumgebung jeweils in projekteigenen Verzeichnisse innerhalb der Produktivumgebung kopiert. Versionierung kann ich leider auch nicht benutzen, deswegen dieser Weg.