Malcolm Beck´s: Generelles zum Caching - Danke!

Beitrag lesen

hi,

Jetzt muss ich mir erstmal überlegen, wie ich dass Generell mit den ganzen Datumsangaben in der DB lösen kann, dass kann ja was werden.

In der Datenbank wirst du ja vermutlich reine Inhalte haben, waehrend deine Navigation in einem include-File lagert.

Nein, ich lese alles aus der DB aus, Inhalte und auch die Gesamte Navigation.
Meine Idee ist jetzt, dass die einzelnen Artikel ein eigenes Datum bekommen, dass ich als Hinweis für den User in der jeweiligen Seite anzeige, in der Tabelle für die Navigation bekommt dann jede Kategorie (die unterseiten hat) ein Datum zugewiesen, dass dann den Last-Modified-Header bildet.
Eventuell lege ich noch ein Feld an, in dem gespeichert wird, wann der Artikel erstmals geschrieben wurde.

Ob der Last-Modified-Header einer Ressource angepasst werden muss, und wie auf einen Conditional-GET-Request mit einem If-Modified-Since-Header zu antworten ist, entscheidet sich also an Hand zweier Kriterien:
Zum einem dem Aenderungsdatum des Inhaltes aus der Datenbank,
und zum anderen dem Aenderungsdatum des include-Files der Navigation.

Und da wird es schon wieder schwierig, wenn ein Artikel eine Aktualisierung bekommt, muss dessen Last-Modified das Aktuelle Datum bekommen, wenn ein Menupunkt hinzukommt, alle Ressourcen dieser Kategoerie.
Wieviele Timestamp werde ich da brauchen?

Wenn deine Ressourcen noch aus weiteren zusaetzlichen Quellen gespeist werden (Template-Dateien, weitere includes mit fuer die Ausgabe relevanten Bestandteilen), dann haben deren Aenderungsdaten natuerlich ebenfalls noch mit in die Betrachtung einzufliessen.

Das mit dem Template wird am schwierigsten, wenn sich das Template ändert, müssten ja Logischerweise alle Ressourcen das Aktuelle Datum als Last-Modified-Header bekommen.
Das werde ich wohl mit einer kleinen Template-Funktion lösen.

mfg

--
„Wenn du nicht bereit bist, dafür zu sterben, dann streiche das Wort »Freiheit« aus deinem Vokabular.“ -- Malcolm X
I Have a Dream