Ja wie jetzt. Absolut oder relativ? Und wenn relativ, WIE relativ? Pfadangaben haben schon so manchen in den Wahnsinn getrieben. Dazu gibt es noch verschiedene Einstellungen - der eine verwendet immer absolute Pfade, der nächste nur relative und ein anderer setzt auf ein Mischverhältnis.
Hier klären wir zunächst, was es in Verbindung mit CSS, HTML, Javascript und der Auflösung relativer Pfade auf sich hat. Dann folgen noch einige Überlegungen zur Strategie im Umgang mit relativen Pfaden…
Zunächst sollte einmal festgehalten werden, das relativ nicht gleich relativ ist - zumindest wenn man bei der Überlegung HTML und CSS mit einander vergleicht. Verwendet man in HTML- und Javascript-Dokumente relative Pfade wird für die Auflösung immer die Basisurl des HTML Dokumentes herangezogen. Folgendes Beispiel erklärt es ganz einfach:
\index.html \images\grafik.gif \js\functions.js \css\styles.css
Wenn man über die eingebundene HTML Datei eine Grafik (grafik.gif) nachläd, kann man es über die relative Pfadangabe images\grafik.gif machen. Da die HTML Datei im Docroot liegt, gelingt die Auflösung.
Möchte man die Grafik allerdings über die URL Funktion von CSS in der styles.css laden, schlägt die Adressierung url(images\grafik.gif) fehl - aber warum? Zur Auflösung von Pfaden über CSS geht der Browser von der URL des CSS Dokumentes aus, funktionieren würde also url(..\images\grafik.gif) - erst aus dem css-Ordner raus und eine Ebene höher, dann in den images-Ordner.
Freunde der absoluten Pfade werden jetzt natürlich lächeln und darauf hinweisen, dass ihre Adressierungsmethode eindeutig ist - \images\grafik.gif ist immer \images\grafik.gif - egal von welchem Dokument aus. Das stimmt aber nur dann, wenn beide Dokumente auf der selben Domain liegen ;)
Der Vorteil der relativen Adressierung ist natürlich, das man das Projekt in einen beliebigen Ordner kopieren kann und es läuft. Unter Live-Bedingungen ein wichtiger Aspekt, gerade wenn es um das Testen eines Beta-Projektes geht. Zur Veranschaulichung gehen wir mal von der Applikation Knaller-App aus, die wurde in Version 0.1 unter der Domain http://www.knaller-app.de gelauncht.
Jetzt steht das zweite Beta-Release 0.2 vor der Tür und damit dem Publikum keine hässlichen Fehler präsentiert werden, wird das Projekt erstmal im Unterordner /beta eingespielt. Bei relativer Adressierung ist das kein Problem, was Zicken macht, sind natürlich absolute Pfade, die im schlimmsten Fall falsche Dateien laden.
Gut. Ich höre Stimmen, die auf eine Applikations-Config pochen, in der der Docroot definiert werden kann. Okay, dann läuft das Projekt wahrscheinlich auch. Eine weitere Möglichkeit wäre eine Subdomain, die auf den Beta-Ordner mappt: http://beta.knaller-app.de löst das Problem auch.
Wie siehts denn mit einem SSL-Zertifikat aus, das auf www.knaller-app.de ausgestellt ist? Die wenigsten Applikationsbetreiber können sich Wildcard-SSL-Zertifikate leisten. Um unter Live-Bedingungen zu testen, muss dann natürlich die Variante von relativen Pfaden in Verbindung mit statischen Template gewählt werden - oder eben eine angepasste App-Config.
Wer sich für die App-Config Variante entscheidet, sollte berücksichtigen, dass es immer Dateien gibt, die wahrscheinlich statisch abgelegt sind und nicht geparst werden. Stylesheets, HTML-Schnipsel (bzw. Templates ;), Javascript-Dateien sind nur einige, die es betreffen kann.
