Malcolm Beck´s: Vanity URLs

Beitrag lesen

હેલો

Werden diese Daten in einer Datei gespeichert?
Klar, das ist eine ini-Datei.
Wofür dann MySQL?
In der ini stehen nur die Routen für die virtuellen Ordner samt Attributen. Im MySQL steht der Content, also URLs mit richtig fetten Bodies ;)

Das ist ja doppelte arbeit für einen Request. Wie oft speicherst du denn eine URL? Einmal in der ini und zusätzlich in der DB?

Bei einem Request auf /foo wird nur dass, was zu /foo gehört aus MySQL gelesen.

So sollte es ja auch sein? Die Links (Pfade) zu den Inhalten sollten sich aus den Inhalten ergeben, keine Extra-Wurst sein. Finde ich zumindest.

Wenn ich Artikel zu den Themen „Programmierung“, „PHP“, „Webseiten“, „HTML“ und „CSS“ habe, ergibt sich die Struktur doch von selbst.

/programmierung
/programmierung/php
/programmierung/php/webseiten
/programmierung/php/webseiten/html
/programmierung/php/webseiten/html/beispiele
/programmierung/php/webseiten/css
/programmierung/php/webseiten/css/beispiele

Natürlich sollte keine der vorangehenden Beispiele in der gezeigten Form gespeichert werden, dass wäre ja völlig absurd.

$self->eav('title' [, 'neuer Title']); # EAV: Entity Attribute Value
das wird dann automatisch ins Template gesetzt.

Ist mir schon klar ;)

Klar, eine HTML-Variante, und das XML-Pendant. Also „/sitemap“ (od. „/sitemap.html“) und „/sitemap.xml“. In beiden Varianten werden aber stets alle Links einer Seite erwartet.
„“
Aufteilen! Unschön, dem Besucher eine Sitemap mit 1000 oder mehr Links zu präsentieren.

Wir waren bei rund 300. Dem User kann und sollte man immer alle vorhalten, aber schön. Und Suchbots werden auch kein Problem mit einer Liste von 1.500 - 2.000 Links haben. Aber seien wir mal Ehrlich, wer kommt schon auf soviel Inhalt auf einer normalen Webseite? Blogs und Foren mit Sicherheit, aber dass ist eine ganz andere Kiste.

બાય

--
 .
..: