Testumgebung, absolute und relative Pfade

[michat]

Hi

mein Projekt liegt (sowohl hier lokal als auch remote auf dem webserver) im rootverzeichnis der Domain "/", wo auch sonst. Dies ist die deutsche version, eine englische und italienische liegt jeweils in "/en/" und "/it/".

Die deutsche testversion befindet sich hier lokal in "/test/" (innerhalb des domainverzeichnisses) und die Sprachversionen entsprechend in "/test/en/" und "test/it/".
Im Grunde bin ich eben erst dabei, diese Sprachversionen innerhalb der Testversion zu vervollständigen und stelle nun fest, dass ich mich - die Gründe sind mir nicht mehr klar - seinerzeit beim Erstellen der Website dazu entschieden hatte absolute Pfade zu nutzen (wobei an dieser Stelle erstmal, zumindest für mich, zu klären ist, was denn wirklich ein absoluter Pfad ist: "example.org/it/" ist absolut, "it/" ist relativ. Aber ist "/it/" absolut oder relativ? Ok, innerhalb einer Domain ist er absolut.)

Wie auch immer, ich hatte hier bislang Pfade ala "/", oder "/it/", "/en/" usw. Und das funktioniert in "/test/" so eben nicht mehr.

Nun bin ich am überlegen, ob ich alles auf relative Pfade umstelle oder ich innerhalb der Testumgebung eben mittels <base href="http://ptac.test/test/" />
das basisverzeichnis ändere. Letzteres müsste ich dann vor dem Hochladen auf den Webserver entweder ändern oder löschen. Erstes wollte ich seinerzeit vermeiden.

Was spricht denn für welche Vorgehensweise?

bye

MH

[Encoder]

wo auch sonst.

Zum Beispiel in "/de/" ?

Was spricht denn für welche Vorgehensweise?

Ich würde auf relativ umstellen, der Rest wäre mir zu undurchschaubar.

Eine ganz andere Idee wäre, die Sprache in einem Cookie (evtl. reicht ein Sessioncookie) zu speichern und dann serverseitig zu entscheiden was du ausgibst. Dann bräuchtest du gar keine Sprachangabe in der URL, bzw. "nur" als Parameter.

[dedlfix]

Tach!

Die deutsche testversion befindet sich hier lokal in "/test/" (innerhalb des domainverzeichnisses) und die Sprachversionen entsprechend in "/test/en/" und "test/it/".

Du hast doch lokal alle Möglichkeiten offen. Warum nimmst du nicht eine eigene (Sub)domain zum Testen? Dann sind zumindest die Pfad-Bedingungen gleich wie im Produktivsystem.

(wobei an dieser Stelle erstmal, zumindest für mich, zu klären ist, was denn wirklich ein absoluter Pfad ist: "example.org/it/" ist absolut, "it/" ist relativ. Aber ist "/it/" absolut oder relativ? Ok, innerhalb einer Domain ist er absolut.)

Von wo aus gesehen? Vom Browser aus gesehen, beginnt der Pfad hinter dem Hostnamen. Denn so fordert er auch die Ressource an: GET /it/. Und wenn du einen relativen Link angibst, wird der zur Ressource des Dokuments, in dem er steht, aufgelöst. Im Dokument /it/ ein it/ zu verlinken ergibt /it/it/. Absolut ist immer mit / am Anfang, relativ ist ohne. - Das Dateisystem des Servers interessiert an dieser Stelle überhaupt nicht. Angeforderte Ressourcen können ja auch sonstwie beantwortet werden, nicht nur mit dem Ausliefern einer Datei.

dedlfix.

[michaa aka michat]

im grunde eist das mit dem speziellen fall der sprachversionen irrelevant.

Mich interessiert was für und was gegen relative Pfade spricht. Die englische version einer Seite ist von der italienischen bei mir absolut unter "/en/seite.html" zu erreichen. Das funktioniert nicht wenn das so in meiner derzeitigen Testumgebung passieren soll weil dann der korrekte Pfad eben "/test/en/seite.html" lauten müsste. Mache ich das relativ dann klappt das unabhängig vom Verzeichnis. Absolut ginge es auch wenn ich in jedem Dokument das Basisverzeichnis neu deklariere. Mit Subdomains möchte ich nicht unbedingt hantieren, weil ich mich dann bestimmt mehrere Stunden (ich brauche solange) mit meiner Apache Konfiguration auseinandersetzen muß. Das blöde ist, irgendetwas sparach für absolute Pfade und ich erinnere mich nichtmehr warum ich das so entschieden hatte.

[dedlfix]

Tach!

Mich interessiert was für und was gegen relative Pfade spricht.

Relative Pfade funktionieren unabhängig vom Basis-Pfad. Absolute Pfade lassen sich oftmals leichter einsetzen, weil man nicht erst prüfen muss, wie die Relationen vom aktuellen Dokument zu den Zielen sind - vor allem, wenn dieses verschoben wird. Händisch kann man das sicher noch prüfen, aber wenn es in einem Script berechnet werden soll, würde ich das nicht wollen.

dedlfix.