Vanity URLs

[hotti]

hi,

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?

Nene ;)
Es gibt noch die Breadcrumb-Geschichte, wenn ich die fertig habe, wird _jeder_ URL in der DB gespeichert sein. Es bleibt jedoch die Haupt-Konfigurationsdatei für den Bootstrap, wo derzeit noch _alle_ EAVs für die virtuellen Ordner drin sind sowie eine Sektion für die Konfiguration.

Bei einem Request passiert folgendes:

my %route = (%config, %eav_hunt);

Merge, gemischt wird noch eine dritte Komponente, die lassen wir hier mal außen vor.

Wobei, in %eav_hunt steht nur der EAV für den jeweiligen Request. E Entity(url) A Attributes V Values
Jetzt haben wir alle Routen, die wir brauchen um den Request durchstellen und eine Response ausgeben zu können. Charakteristisch für mein FW ist die Bindung der URL an eine Klasse, welche das ist, steht im class-Attribut (z.B.: class=DBResponse => das Template kommt aus MySQL).

Btw., die Klasse kann eine Controller-Class sein mit einem eigenen Controller, oder der Controller wird namentlich über das control-Attribut zugewiesen (class=DBResponse hat z.B. keinen eigenen Controller). Ich habe sog. Kompakt-Klassen, da ist alles in einer Datei, der Controller und auch das Template. Beispielsweise ist der Mayakalender eine solche Kompaktklasse, Attribute class=MayaControl.

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.

Genau das ist der merge-Hack: $self->{BIN} kriegt eine Referenz auf \%route und dann wird alles über einen Kamm geschert ;)
Das Gute daran ist das Gute darin: In jeder zum FW-Interface gehörigen Methode kann der Singelton auf jedes beliebige Attribut zugreifen, also auch auf Attribute derjenigen URLs die nicht selbst die Response sind, im Rahmen der Ordner-Virtualisierung jedoch zum gleichen Ordner der auszugebenden Response gehören.

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.

Bleistifte humpeln grundsätzlich. Wenn es jedoch gelingt, eine physikalisch abgebildete Ordner/Datei-Struktur nach Attributen umzusetzen, so dass der Zusammenhalt nicht verloren geht, ist das auch ok. Zusammenhalt meint:

Ein Request auf /programmierung/php/webseiten/css erzeugt in der Response die Breadcrumb /programmierung/php/webseiten und irgendwo die Links zu den anderen URLs im gleichen Ordner-Pfad. Dann kann der Besucher auch navigieren.

Nun ists aber so, dass Dateiattribute so ganz und gar nicht zu Attributen passen, die zum Darstellen der Inhalte im Browser notwendig sind. Formal gesehen passt lediglich der Baum, aber das wars schon. Wo tu ich title, descr usw. hin, so meine Überlegungen bereits vor 10 Jahren und wenn ich meinen Kram schon selbst verwalte, dann kann ich mich auch komplett von Dateisystem trennen.

Hierarchien: Ich habe viel gelesen (und auch damit programmiert) über Nested Sets und das Adjacency List Model. Ich verwende Letzteres und reduziere das auf eine Parent-Relation, d.h., in Bezug auf persistent Objects muss ein URL nur seinen Parent kennen, die persistente Datenhaltung reduziert sich auf ein einziges zusätzliches Attribut.

Bei einer Hierarchie im Dateisystem ist das genau umgekehrt, ich würde über den Ordner die zugehörigen Dateien ermitteln. Programmiertechnisch ist es jedoch keine Ressourcenfresserei, eine Parent-Relation in eine Child-Relation umzudrehen, DB-gestützt oder code-based. Und nur das Sitemap braucht diese Umkehrung, für alles Andere reicht die Parent-Relation.

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.

Ich bin mittlerweile 57 und hab ne Menge zu erzählen ;)

Horst