CSS Pfade

[blinder]

Hallo,

mal folgende Frage: für meine Webprojekte habe ich ein config-File, in dem die Pfade festgelegt werden.

  
/*some code here*/  
  
$config["path_img"] = "images/";  
$config["path_product_img"] = $config["path_img"]."products/";  
$config["path_layout_img"] = $config["path_img"]."layouts/";  
  
/*some more code goes here*/  

Der Vorteil liegt ja auf der Hand. Ich muss jeden Pfad nur einmal eingeben. Ander Parameter werden ebenfalls so festgelegt. (Alternativ verwende ich ein config-File, welches ich mit  parse_ini_file einlese. Das nur nebenbei).

Nun meine Frage:

In den eingebundenen CSS-Dateien muss ich den Pfad für eventuelle Hintergrundbilder jeweils manuell eingeben, da ich diese Dateien nicht mit PHP parsen lasse. Das ist natürlich nicht optimal. Wie macht man denn sowas am besten? Ich will *jede* verwendete URI nur *einmal* eingeben.

Blinder

[ChrisB]

Hi,

In den eingebundenen CSS-Dateien muss ich den Pfad für eventuelle Hintergrundbilder jeweils manuell eingeben, da ich diese Dateien nicht mit PHP parsen lasse. Das ist natürlich nicht optimal. Wie macht man denn sowas am besten?

Man überlegt sich vorher, wo in Relation zur CSS-Ressource man die Bilder ablegen möchte.

MfG ChrisB

[Blinder]

Hi

Man überlegt sich vorher, wo in Relation zur CSS-Ressource man die Bilder ablegen möchte.

Gut, das ist ja sowieso klar.
Aber nehmen wir an, ein User, der meine Software benutzt, möchte seine (Hintergrund-)Bilder eben woanders haben, als standardmäßig festgelegt. Dann sollte er auch den Pfad entsprechend setzen können.

ich werde doch die CSS-Dateien serverseitig zusammenbauen und dann entsprechendes Caching verwenden. Anders kann es ja auch nicht funktionieren.

Blinder

[ChrisB]

Hi,

ich werde doch die CSS-Dateien serverseitig zusammenbauen und dann entsprechendes Caching verwenden.

Ich würde das effektivste nutzen: Statische Dateien im Dateisystem.

Wenn die Pfade geändert werden, kann man ja ein Script anstoßen, welches diese Dateien neu generiert.

MfG ChrisB

[Blinder]

Hi

Ich würde das effektivste nutzen: Statische Dateien im Dateisystem.

Wenn die Pfade geändert werden, kann man ja ein Script anstoßen, welches diese Dateien neu generiert.

Hm, stimmt. Die Idee ist nicht schlecht. Werde ich mir mal durch den Kopf gehen lassen.

By the way, die URIs erst in den jeweiligen Dokumenten zu definieren, ist keine gute Idee, oder? D.h., in der CSS-Datei werden die Eigenschaften für das Hintergrundbild (Position, Ausrichtung, Wiederholung) definiert, in dem jeweiligen HTML-Dokument dann mit Hilfe des style-Elements im Head-Bereich die URI.

  
#navigationLeft{background-image:url(<?php echo $config[$path_layout_images];?>)}  

Blinder

[ChrisB]

Hi,

By the way, die URIs erst in den jeweiligen Dokumenten zu definieren, ist keine gute Idee, oder? D.h., in der CSS-Datei werden die Eigenschaften für das Hintergrundbild (Position, Ausrichtung, Wiederholung) definiert, in dem jeweiligen HTML-Dokument dann mit Hilfe des style-Elements im Head-Bereich die URI.

#navigationLeft{background-image:url(<?php echo $config[$path_layout_images];?>)}

  
Das könnte man in Einzelfällen vielleicht mal machen, aber als generelle Lösung ist es nicht empfehlenswert, nein.  
  
MfG ChrisB  
  

-- 
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

[dedlfix]

Hi!

In den eingebundenen CSS-Dateien muss ich den Pfad für eventuelle Hintergrundbilder jeweils manuell eingeben, da ich diese Dateien nicht mit PHP parsen lasse. Das ist natürlich nicht optimal. Wie macht man denn sowas am besten? Ich will *jede* verwendete URI nur *einmal* eingeben.

Es gibt nur die beiden Möglichkeiten: zu Fuß oder programmatisch. Wenn du ersteres nicht willst, musst du dir ausdenken, wie du zweiteres realisieren kannst. CSS kennt nach meinem Wissensstand keine Variablen, also musst du das CSS-Dokument auf dem Server zusammenbauen oder mit einer anderen Platzhalterersetzungstechnik bearbeiten.

Lo!

[hotti]

hi,

... Wie macht man denn sowas am besten? Ich will *jede* verwendete URI nur *einmal* eingeben.

Ich empfehle absolute Pfadangaben (/index.htm, /default.css), jedoch nicht auf das Dateisystem bezogen sondern auf DOCUMENT_ROOT, was im Webserver konfiguriert ist. Damit ergeben sich auch so manche Vereinfachungen und keine Abhängigkeiten, die vermeidbar sind.

Solche Pfadangaben funtionieren auch, wenn bei einem Umzug DOCUMENT_ROOT geändert wurde. Das kürzt sich dann raus, weißt Du ;-)

Einziger Nachteil: Es braucht einen Webserver.

Horst Huckepack

PS: Mein CMS ist ohne solche Pfadangaben nicht denkbar, nicht nur von der 100% igen Garantie, dass alle Refs funktionieren, sondern auch vom Programmieren her. Wie gesagt: Keine Abhängigkeiten.

[blinder]

Hallo Hotti,

Ich empfehle absolute Pfadangaben (/index.htm, /default.css), jedoch nicht auf das Dateisystem bezogen sondern auf DOCUMENT_ROOT, was im Webserver konfiguriert ist. Damit ergeben sich auch so manche Vereinfachungen und keine Abhängigkeiten, die vermeidbar sind.

Aha, ok. Ich bin neu in Sachen CMS-Programmierung, aber ich bastele mir seit geraumer Zeit auch eins :)
Alle meine Pfadangaben sind ebenso absolut zu DOCUMENT_ROOT, ich mache das dann so in der ARt:

  
  
$php_path = $_SERVER['DOCUMENT_ROOT']."path/to/php/";  
  

Weiss nicht, ob das das ist, was du meinst...

Blinder

[hotti]

hi,

$php_path = $_SERVER['DOCUMENT_ROOT']."path/to/php/";

>   
> Weiss nicht, ob das das ist, was du meinst...  
  
Genau. Mit DOCUMENT\_ROOT davorgeschaltet kriegst Du den Pfad zum Dateisystem. Ansonsten beginnen  
  
REQUEST\_URI, SCRIPT\_NAME  
  
mit dem Slash und so halte ich das auch mit allen anderen Pfadangaben. Was PHP'ler vielleicht nicht so wissen, es gibt für Perl/CGI meistens ein virtuelles Verzeichnis /cgi-bin/, ein Script heißt dann z.B. /cgi-bin/script.pl  
  
/cgi-bin/ ist in der Serverkonfiguration der ScriptAlias und virtuell. Das kleinste gemeinsame Vielfache ist auch hierbei eine Pfadangabe, die mit dem "/" geginnt.  
  
Ein Perl-CMS, also ein Script was den Content aus der Konserve zaubert und selbst in einem virtuellen Pfad liegt, braucht grundsätzlich eine virtuelle Pfadangabe für z.B. eingebundene Images, sonst passt die Referenz nicht, guck mal:  
  
 http://rolfrost.de/screenshots.htm (s. Quelltext)  
  
hierbei ist auch mod rewrite im Spiel, du siehst o.g. URI, das Script jedoch liegt im virtuellen Verzeichnis /cgi-bin/ <= hier würden sowohl absolute als auch relative auf das FS bezogene Pfadangaben nicht funktionieren.  
  
Viele Grüße,  
Horst Huckepack

-- 
Theoretisch endet ein 32 Bit UNIX-Timestamp in ein paar Jahren, praktisch ist mir das egal ;-)

[Blinder]

Hi Hotti,

danke! Mas was anderes. Soweit ich hier Pico sehen kann, trägst du HTML-Code in die DB ein. Wie ist das mit komplexeren Geschichten (floatende divs, listen, tabellen, etc), trägst du das auch als HTML in die DB ein? Bin nämlich am überlegen, ob ich die Inhalte nicht "pure" belassen sollte und erst in der Ausgabe dann entsprechend auszeichnen...

Blind as ever

[hotti]

Mahlzeit,

danke! Mas was anderes. Soweit ich hier Pico sehen kann, trägst du HTML-Code in die DB ein. Wie ist das mit komplexeren Geschichten (floatende divs, listen, tabellen, etc), trägst du das auch als HTML in die DB ein? Bin nämlich am überlegen, ob ich die Inhalte nicht "pure" belassen sollte und erst in der Ausgabe dann entsprechend auszeichnen...

Das Eintragen in die DB ist in meinem Konzept so, dass nur der Body komplett mit allen HTML Tags in den Datenspeicher kommt. Das "obendran" <head>...</head> wird dynamisch aus den Properties erzeugt, diese sind title, descr, author usw. Das Speicherobjekt sieht in etwa so aus:

$o->{body};   # native HTML
$o->{title};  # pure Text
$o->{descr};  # pure Text
$o->{author}; # pure Text usw. dazu kommen noch die Links zu JS und CSS.

Formatierungen/Design sind per CSS vorgesehen. Freilich kannst Du das noch weiter treiben, also auch den Body in Attribute zerlegen und beim Auslesen wieder zusammenbauen.

Wobei: "Attribut" hat jetzt eine doppelte Bedeutung, einmal sind das die attr in den Tags <a title class id> nach der HTML-Spezifikation und zum Anderen ist innerhalb des CMS <title> selbst auch ein Attribut bzw. eine Property (CMS-Objekt-Attribute, HTML-Attribute).

Es ist die Frage, welchen Aufwand Du betreiben möchtest, machbar ist alles. Ich denke, ein $o->{body} als native HTML ist ein guter Kompromiss. Fakt is: Machs mit OOP, alles Andere führt zum Chaos ;-)

Viele Grüße,
Horst Huckepack