ChrisB: include_path und __autoload gemeinsam nutzen

Beitrag lesen

Hi,

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.

Wenn man den include_path für jedes Projekt separat definiert, kann man dort doch zunächst A angeben, und dann anschliessend noch die jeweils projektspezifischen Verzeichnisse.

Soweit die Entwicklungsumgebung. In der Produktivumgebung sollte es gerade umgekehrt laufen. Zunächst werden die projektspezifischen Verzeichnisse durchsucht, danach das oder die allgemeinen Klassenverzeichnisse.

Dann definiert man in der produktiven Umgebung die include_path jeweils umgekehrt.

Das stellt natürlich eine potentielle Fehlerquelle dar - aber wenn man das klar dokumentiert (insb. den Anpassungsprozess des include_path bei der Produktivsetzung) und dabei ein festes Muster streng einhält, halte ich das für nicht allzu kritisch.

Aber um auch dieses Risiko zu vermeiden, ist der andere Weg vielleicht doch der bessere:

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?

Wenn im Testsystem die Dateien für alle Projekte unter
/xyz/a/
liegen, und später aber jeweils individuell unter
/xyz/project1/b/
/xyz/project2/c/
/xyz/project3/d/
liegen werden - dann könnte man auf dem Testsystem doch schon Symlinks einrichten, die die "Pseudo-Verzeichnisse" /xyz/project1/b/, /xyz/project2/c/ und /xyz/project3/d/ simulieren, und alle auf /xyz/a/ zeigen lassen.

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.

Dann erscheint mir eine Lösung mit Symlinks noch attraktiver. Den Projekten wird schon während der Entwicklung ein eigenes Projektverzeichnis "vorgegaukelt", das im Hintergrund auf das gemeinsame Verzeichnis "umgelenkt" wird. Die Projekte selber "merken" gar nichts davon, dass sie sich in dieser Phase noch aus einem gemeinsamen Verzeichnis "bedienen".

MfG ChrisB

--
Light travels faster than sound - that's why most people appear bright until you hear them speak.