generierte Inhalte einbinden

[molily]

Hallo,

Ich könnte jetzt die Pfade absoluter machen, das wäre aber eine schöne Katastrophe, wenn ich den ganzen Kram vom Verz "baustelle" in die Wurzel verschiebe!!!

Absolute Pfade sind schon der richtige Ansatz. Eine andere (Sub-)Domain hilft hier, damit du nicht mit der aktuellen Site in Konflikt kommst.

Webframeworks benutzen i.d.R. zentrale Funktionen, um die URLs in Links, Formularen usw. generieren. Wenn die URLs zentral generiert werden, ist es kein Problem, ein Präfix wie »/baustelle/« vor jede URL zu setzen.

Aber wie kann ich diese halbwegs separat betreiben? Also, daß header, kopf, content und fuss die "folkadelic.css" benutzen, und NUR im content_shop die /shop/shop.css genutzt wird? Während auf dieser Seite immer noch header, kopf und fuss die folkadelic.css nutzen? Ist mir irgendwie rätselhaft...

Das ist eine Frage der sinnvollen Verwendung von Selektoren und Regeln.

Im Allgemeinen:

Erzeuge wiederverwendbare HTML/CSS-Module, die auf verschiedenen Seiten / in verschiedenen Kontexten verwendet werden:

.modul { … }  
.modul .teil-vom-modul { … }

Im Kontext von gewissen Seiten oder Seitenelementen kannst du diese umformatieren, beispielsweise:

.kontext .modul { … }  
.kontext .teil-vom-modul { … }

Konkret:

Formatiere den Header und darüber seine Nachfahrenelemente durch Vererbung von CSS-Eigenschaften:

#header { … }

Formatiere gewisse Elemente im Header:

#header h1 { … }

Formatiere den Shop und seine Nachfahrenelemente:

.shop { … }  
.shop .foo { … }

Die shop-Klasse kann hier entweder an einem div, section oder direkt am body-Element hängen. Im letzten Fall lassen sich die Formatierungen für sämtliche Seitenelemente ergänzen/überschreiben:

.shop #header { … } /* Besondere Styles für den Header auf der Shop-Seite */

Wenn du HTML & CSS so anlegst, dass es allgemeine und spezielle, überschreibende Regeln gibt, so kannst du sämtliche Formatierungen gleichzeitig laden, ohne dass sie sich in die Quere kommen. (So würde ich erst einmal arbeiten, nicht mit unterschiedlichen Dateien, die sich ausschließen.)

Die Entscheidung, 2 php's zu betreiben, lag vor allem darin, daß ich nicht bei jedem Klick einen riesigen Wust an Daten wälzen muß, diese auswerten, und dann am Ende noch ein maßgeschneidertes html ausspucken zu lassen. Es ist doch viel ressourcen-schonender einen separaten Warenkorb zu haben, der nichts weiter macht, als die Waren vom shop_content entgegenzunehmen mit den wichtigsten Daten

Ja, es ist in dieser Hinsicht ressourcenschonenend, in einer anderen Hinsicht vergeudet es Ressourcen. Die serverseitige Komplexität ist geringer, wenn du einfache PHP-Dateien hast, die genau für *eine* Funktion zuständig sind (»Single Responsibility Principle«). Allerdings braucht es genauso Ressourcen, diese verschiedenen Teile sauber zusammenzubringen – mit Iframes, vielen HTTP-Anfragen, mit JavaScript, redundanten CSS-Dateien usw.

Es ist nicht falsch, Iframes zu verwenden, um nicht immer riesige Dokumente auf dem Server zusammenfügen und übertragen zu müssen. Der Ajax-Ansatz geht in dieselbe Richtung und ist mittlerweile etabliert. Letztlich ist das Erzeugen von immer neuen, großen HTML-Dokumente auf dem Server einfacher und robuster als clientseitige Magie mit Iframes, JavaScript/Ajax. Das sage ich als jemand, der hauptsächlich JavaScript-Anwendungen entwickelt.

Grüße,
Mathias