include_path und __autoload gemeinsam nutzen

[Johannes3]

Hallo

Hi,

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.

Schon, aber dann muß ich ja auch wieder jeweils A für jedes Projekt definieren. Ich dachte an eine Möglichkeit, dieses eine Verzeichnis wirklich einmalig in der php.ini einzutragen, so daß es dann immer direkt allen Projekten zur Verfügung steht.

»

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.

Diese Lösung scheint auch ein gangbarer Weg.

Wie symbolische Links funktionieren, weiß ich ja, ich weiß nur leider nicht, wie ich sie praktisch umsetzen kann, sowohl was die Shell als auch was PHP betrifft.

Ich erkläre mal kurz, wie ich Dich verstehe. Die Klassen kommen (in der Entwicklungsumgebung) nach /xyz/a/. In PHP selbst (mittels inc_path, ini_set etc.) greift man auf Dateien aus /xyz/projekt1/b/ zu. Dort liegen aber keine gewöhnlichen Dateien, sondern Links. Das merkt PHP selbst nicht, wohl aber das OS. Also müßte ich in /xyz/projekt/b// für jede Datei einen Link auf ein Pendant in xyz/a/ anlegen. Verstehe ich das soweit richtig?

Der einzige Schritt, der getan werden muß, läge demnach gar nicht in der Programmierung mit PHP, sondern im Anlegen von symb. Links mittels Shell, ist das so richtig?

Wenn das so wäre, würde das sogar noch ein anderes Problem lösen, nämlich wenn sich herausstellt, daß eine Applikation doch nicht fehlerfrei arbeitet und noch mal in der Entwicklungsumgebung nachbearbeitet werden muß. Jetzt bestünde natürlich die Möglichkeit, daß verwendete Klassen im allgemeinen Verzeichnis verändert wurden und nicht mehr kompatibel zum fehlerhaften Projekt sind. Ich könnte in dem Fall aber vorübergehend den symb. Link durch die tatsächliche Klasse in xyz/fehlerhaftes_projekt/a/ ersetzen, und das Problem wäre gelöst. Das wäre eine sehr sympathische Lösung, und wenn dies funktioniert, bin ich Dir sehr dankbar, daß Du mir diese Perpektive eröffnet hast.