Vanity URLs

[hotti]

hm,

sowas hier:
http://www.example.com/aktuelles/presseinformationen/artikel/artikeldetail/tunguska_katastrophe_beweise_fuer_sauren_regen_stuetzen_meteoritentheorie/

ist das so etwas?

Ein http://www.example.com/fallout.html hätte doch auch gereicht, oder hab ich was verpasst?

Horst Sauer

[T-Rex]

Nein ein
http://www.example.com/aktuelles/presseinformationen/artikel/artikeldetail/tunguska_katastrophe_beweise_fuer_sauren_regen_stuetzen_meteoritentheorie/

Soll angeblich ein
Schau mal Google ein tolles Keyword: "aktuelles"
und noch eins "presseinformationen"
und noch eins "artikel"
sein.

Zudem verstehen einige Zuständige nicht das die Pfadangabe rein gar nichts mit der Webseitenstruktur zu tun hat. Mein Chef beispielweise ist der Überzeugung dass es die Seite http://www.example.com/aktuelles/ geben muss, da sonst die anderen Pfadangaben nicht gesetzt sein können. Das da alles lose zusammenhängende URLs sind wird der auch nie raffen. Und so wird immer versucht dem User eine ähnliche Ordnerstruktur zu geben wie in Windows. Nur eben auf URL ebene und mit "Verzeichnissen".

Gruß
Googles Keyword Nr. 1
T-Rex

[Jörg Reinholz]

Zudem verstehen einige Zuständige nicht das die Pfadangabe rein gar nichts mit der Webseitenstruktur zu tun hat.

Ja, man kann und muss da (bei CMS) mit mod_rewrite einiges biegen ...

Mein Chef beispielweise ist der Überzeugung dass es die Seite http://www.example.com/aktuelles/ geben muss, da sonst die anderen Pfadangaben nicht gesetzt sein können.

Ersetze mal 'muss' durch 'soll' dann passt es. Denke auch an die "Suchstrategie" von Benutzern der Seite. Die bearbeiten auch die URL direkt und erwarten unter http://www.example.com/aktuelles/ was zu finden. Also liefere dort "was sinnvolles".

Und so wird immer versucht dem User eine ähnliche Ordnerstruktur zu geben wie in Windows. Nur eben auf URL ebene und mit "Verzeichnissen".

Ja. Eben. Man gebe dem Kunde oder Informationssuchenden was er will.

Jörg Reinholz

[hotti]

hi,

Ja. Eben. Man gebe dem Kunde oder Informationssuchenden was er will.

Oder auch nicht. Z.B. erwarten viele ein /impressum.html um dort an die Kontaktdaten heranzukommen, die sie brauchen um ihren SPAM loszuwerden. Seitdem ich das, was einst auf meinem /impressum.html stand, nunmehr auf jeder Unterseite platziert habe, hat sich das SPAM-Aufkommen sehr deutlich verringert ;)

Horst Haselhuhn, Legehennenexperte

[T-Rex]

Wäre ich ein Bot, dann würde ich auf jeder Seite nach einer validen E-Mail Adresse gucken.

Gruß
BoT-Rex

[hotti]

hi,

Zudem verstehen einige Zuständige nicht das die Pfadangabe rein gar nichts mit der Webseitenstruktur zu tun hat.

Ja ;)

Ich arbeite schon immer mit virtuellen Ordnern. Das hat den Vorteil, dass der URL erhalten bleibt, wenn die Seite einen anderen Parent (virtuellen Ordner) bekommt.

Aber zurück zum Ausgangspost. Bei dem und ähnlichen http://example.org/Moechte_gern_Vanity_URL_sein_und_leicht_zu_merken_URLS.html versuche ich mir manchmal vorzustellen, wie das einer auf seinem Handy eingibt und sich beim .html noch daran erinnert, wie das Ding am Anfang heißt. Und wenn schon, dann Case sensitive, jawoll!

Das sind nicht Eitel-URLs sondern Eiter-URLs.

Horst Henne

[M.]

Mahlzeit,

Das sind nicht Eitel-URLs sondern Eiter-URLs.

Vorallem nichtmal richtig wirkungsvoll. Ein Bindestrich ist der viel bessere Trenner als ein Unterstrich.
Allerdings ist sowas nur für SuMas sinnvoll, für Menschen ist das nicht lustig ;)

[hotti]

hi,

Allerdings ist sowas nur für SuMas sinnvoll,

Das behaupten viele. Ich vermute mal, das sind diejenigen, die mit URL-Parametern gar nicht richtig umgehen können. Nach nunmehr fast 15 Jahren, die ich mich mit meinen Seiten im Internet rumtreibe, habe ich jedenfalls festgestellt, dass Webressourcen, bei denen das letzte Stück zur Ausgabe einer Response von einem Parameter bestimmt wird, in den Suchmaschinen genausogut platziert sind, wie Seiten ohne Parameter.

Straight ahead!
Horst

[M.]

Mahlzeit,

Das behaupten viele. Ich vermute mal, das sind diejenigen, die mit URL-Parametern gar nicht richtig umgehen können.

Ja, das wirds sein. Dass dabei auch Mitentwickler von Google sind, zeigt, dass die ihr eigenes System nicht kennen. Verdammt haben die ein Glück, dass es dich gibt ...

[hotti]

Mahlzeit,

Das behaupten viele. Ich vermute mal, das sind diejenigen, die mit URL-Parametern gar nicht richtig umgehen können.

Ja, das wirds sein. Dass dabei auch Mitentwickler von Google sind, zeigt, dass die ihr eigenes System nicht kennen. Verdammt haben die ein Glück, dass es dich gibt ...

Gerne lerne ich dazu. Leg mal Deine Ironie beseite und gib mir Links/Lesestoff wo ich das, was Du weiter oben schreibst, direkt von Google-Mitarbeitern nachlesen kann.

Horst

[M.]

Mahlzeit,

Leg mal Deine Ironie beseite und gib mir Links/Lesestoff wo ich das, was Du weiter oben schreibst, direkt von Google-Mitarbeitern nachlesen kann.

Das was ich mit einigen Programmierern in der Kneipe rede oder privat korrespondiere, werde ich sicher niemanden zum nachlesen geben ;)
Das dürfte auch einer der ganz wenigen Punkte sein, den ich zum Thema weitergebe.

Ob du es glaubst oder nicht, ist mir grundsätzlich egal. Wenn du Menschen mit anderer Aussage aber erstmal als Unfähig hinstellst, ist das ziemlich unverschämt.

[hotti]

hi,

Ob du es glaubst oder nicht, ist mir grundsätzlich egal. Wenn du Menschen mit anderer Aussage aber erstmal als Unfähig hinstellst, ist das ziemlich unverschämt.

Dass es viele Entwickler gibt, die mit URL-Parameter nicht richtig umgehen können, ist eine Erfahrung. Dass es dieselben sind, die behaupten, URL-Parameter wären für die Suchmachinen schlecht, das ist eine Vermutung. Und als solche auch in meinem Post gekennzeichnet.

Horst

[Jörg Reinholz]

Ich darf den sich anbahnenden Streit beenden. Was Google selbst dazu sagt. PDF, deutsch

[hotti]

Ich darf den sich anbahnenden Streit beenden. Was Google selbst dazu sagt. PDF, deutsch

Herzlichen Dank!!!!!

Horst Herzlich

[T-Rex]

Allerdings ist sowas nur für SuMas sinnvoll, für Menschen ist das nicht lustig ;)

Nicht mal mehr das.
Google soll seit einiger Zeit die Priorität der URL sehr zurück geschraubt haben. Ist auch verständlich. Die htaccess "tricks" sprechen sich herum. Die URL ist genau so manipulierbar wie die Key und Descibtion Metas.
Aber man kann ja als Entwickler sagen was man will. Wenn man keine SEO Suchmaschinen Hefte zum Frühstück isst hat man offiziell keine Ahnung.

Gruß
Ballaststoff Verwerter
T-Rex

[hotti]

hi,

Aber man kann ja als Entwickler sagen was man will. Wenn man keine SEO Suchmaschinen Hefte zum Frühstück isst hat man offiziell keine Ahnung.

Genau: Denken Sie daran, dass Sie ersteinmal was essen müssen, bevor Sie irgendwas zum Kotzen finden.

Horst

[Jörg Reinholz]

Aber man kann ja als Entwickler sagen was man will. Wenn man keine SEO Suchmaschinen Hefte zum Frühstück isst hat man offiziell keine Ahnung.

Wie das so mit dem "offiziell" ist. Praktisch, so denke ich begründet, schlagen wir beide und noch so einige der hiesigen Stammposter so manchen, der das Frühstück für die "SEO-Heft-Fresser" zusammenschreibt.

Jörg Reinholz

[M.]

Mahlzeit,

Google soll seit einiger Zeit die Priorität der URL sehr zurück geschraubt haben. Ist auch verständlich. Die htaccess "tricks" sprechen sich herum. Die URL ist genau so manipulierbar wie die Key und Descibtion Metas.

Das ist auch meine Erfahrung. Entscheidend sind die Inhalte.

[Malcolm Beck´s]

હેલો

sowas hier:
http://www.example.com/aktuelles/presseinformationen/artikel/artikeldetail/tunguska_katastrophe_beweise_fuer_sauren_regen_stuetzen_meteoritentheorie/

ist das so etwas?

Ein http://www.example.com/fallout.html hätte doch auch gereicht, oder hab ich was verpasst?

Eine URL, ja ;)

Ob du die Dateiendung hinten dran hängst oder nicht, spielt keine Rolle (ich lasse sie weg, da sie für den User ohnehin null aussagekraft hat). Aber als keywords lassen sich die URLs auf jedenfall nutzen. Schrieb sogar Google irgendwo. Und ob am ende ein Slash ist oder nicht, ist auch wurscht.

બાય

[hotti]

hi,

sowas hier:
http://www.example.com/aktuelles/presseinformationen/artikel/artikeldetail/tunguska_katastrophe_beweise_fuer_sauren_regen_stuetzen_meteoritentheorie/

ist das so etwas?

Ein http://www.example.com/fallout.html hätte doch auch gereicht, oder hab ich was verpasst?

Eine URL, ja ;)

Lange Ottooooooooooooooos vermeiden, Empfehlung von gooooooooooooooogle, war schon immer so. Die Gründung der Gilde der URL-Shortener ist mir glatt am Podex vorbeigegangen ;)

Ob du die Dateiendung hinten dran hängst oder nicht, spielt keine Rolle (ich lasse sie weg, da sie für den User ohnehin null aussagekraft hat).

Ich nur wegen der Übersicht, meine virtuellen Ordner haben i.d.R. keine Endung und ein /foo.html wird i.d.R. HTML ausliefern und ein /foo.html?pdf=1 eventuell die PDF-Version von /foo.html und ein /foo.jpg ist i.d.R. ein Bild.

Aber als keywords lassen sich die URLs auf jedenfall nutzen. Schrieb sogar Google irgendwo. Und ob am ende ein Slash ist oder nicht, ist auch wurscht.

Ein /foo.html/ sieht irgendwie komuisch aus, ein /foo.html/bar/ noch komuischer, geht aber auch.

Horst

[Malcolm Beck´s]

હેલો

Lange Ottooooooooooooooos vermeiden, Empfehlung von gooooooooooooooogle, war schon immer so. Die Gründung der Gilde der URL-Shortener ist mir glatt am Podex vorbeigegangen ;)

Ottoooooos ist nicht gleich Ottoooooos. Wenn du auf einer Seite viele unterseiten mit viel Inhalten hast, musst du diese ja irgendwie kategorisieren. Eignet sich halt nebenher gut für Keywords. Für eine Handvoll unterseiten wäre das Kategorisieren auch zuviel des guten. Da reicht deine Variante völlig.

Ein /foo.html/ sieht irgendwie komuisch aus, ein /foo.html/bar/ noch komuischer, geht aber auch.

So soll man es ja auch nicht machen ;)

બાય

[hotti]

hi,

Ottoooooos ist nicht gleich Ottoooooos. Wenn du auf einer Seite viele unterseiten mit viel Inhalten hast, musst du diese ja irgendwie kategorisieren.

Achso, ja, jetzt ich weiß was Du meinst. Nun, ich löse die Frage der Ordnerzugehörigkeit nicht über den URL sondern über ein inneres Attribut. War schon immer so ;)

Horst Proper

[Malcolm Beck´s]

હેલો

Achso, ja, jetzt ich weiß was Du meinst. Nun, ich löse die Frage der Ordnerzugehörigkeit nicht über den URL sondern über ein inneres Attribut. War schon immer so ;)

Wie würdest du denn diese Seite strukturieren? Die Ordnernachbildung ist doch gut?

બાય

[hotti]

hi,

Wie würdest du denn diese Seite strukturieren? Die Ordnernachbildung ist doch gut?

Ja, das ist sie. Bei mir sieht das ganz ähnlich aus: das Sitemap.

In dieser ul/li sind jedoch nur meine virtuellen Order verlinkt, die Unterseiten würden den Rahmen einer solchen Liste sprengen, das sind derzeit fast 300. Meine virtuellen Ordner haben i.d.R. URLs, ohne .html und sind ohne trailing '/', das kann ich jedoch machen wie ich will (hier ist mir nur die Konsistenz etwas aus der Reihe getanzt, dass manche virt. Ordner auch mal .html heißen wie z.b. /garten.html).

Es gibt aber auch virt. Ordner bei mir, die so aussehen: http://rolfrost.de/kraichgau/ wobei die darin enthaltenen Unterseiten den Pfad mitschleifen (z.B. http://rolfrost.de/kraichgau/leinburg oder http://rolfrost.de/single/kalterhund.html).

In jedem Fall hat jeder meiner URLs ein Attribut isa=folder wenn es sich um einen Folder (virtuellen Ordner) handelt, das isa-Attribut ist nach außen hin nicht sichtbar und macht zum Anderen den Aufbau einer Hierarchie unabhängig vom URL, so kann ich beispielsweise Unterseiten einem anderen virtuellen Ordner zuweisen ohne die URLs der Unterseiten zu verändern. In einem solchen Fall muss nur das parent-Attribut der betreffenden Unterseite geändert werden, das ist nicht einmal Minutensache.

Das Sitemap (Link s.o.) ist optisch auch für mich ganz hilfreich, organisatorisch betrachtet ;)

Ansonsten ist bei mir auch das URL-Routing völlig unabhängig von URls und davon frei konfigurierbar. In den letzten Tagen habe ich da noch optimiert, was den Performance und Hauptspeicherbedarf der Routing-Table betrifft, im Hauptspeicher landet immer nur ein Teil der Routingtable, die wahlweise aus MySQL oder aus einer Objekt-Datei erstellt werden kann (Austausch des Layers ist Minutensache, z.Z. läuft die Site über die Objekt-Datei und nur wenige URLs bekommen einen MySQL-Verbindung wie z.B. der Mondphasenkalender). Für die Objekt-Datei habe ich einen eigenen Serializer entwickelt, damit sind gezielte Abfragen auf die Objekt-Datei möglich, ohne dass diese Datei komplett in den RAM gelesen werden muss.

Ebenfalls per Konfiguration kann jeder meiner URLs einen Kontroller bekommen der auch Platzhalter fürs Template von nicht-interaktiven Unterseiten initialisieren kann, wie z.B. das Datum in der Starseite, aber das ist eine andere Geschichte...

Horst

[Malcolm Beck´s]

હેલો

In dieser ul/li sind jedoch nur meine virtuellen Order verlinkt, die Unterseiten würden den Rahmen einer solchen Liste sprengen, das sind derzeit fast 300.

Naja, in einer Sitemap erwartet man alle Seiten, unabhängig von der Anzahl. Wichtig ist dann nur, dass die Seiten richtig struturiert angezeigt werden, sprich der Baum auch ein Baum ist.

Meine virtuellen Ordner haben i.d.R. URLs, ohne .html und sind ohne trailing '/', das kann ich jedoch machen wie ich will (hier ist mir nur die Konsistenz etwas aus der Reihe getanzt, dass manche virt. Ordner auch mal .html heißen wie z.b. /garten.html).

Die Dateiendungen sind eigentlich unnötig. Ich weiss, du brauchst sie für die üersicht, aber an und für sich werden sie nicht empfohlen (ab Seite 8).

In jedem Fall hat jeder meiner URLs ein Attribut isa=folder wenn es sich um einen Folder (virtuellen Ordner) handelt, das isa-Attribut ist nach außen hin nicht sichtbar und macht zum Anderen den Aufbau einer Hierarchie unabhängig vom URL

Warum einfach, wenn man's sich schwer machen kann?  ;)

Ich denke nicht in Ordnern, dass ist wohl das Problem. Für mich sind Links in einem Menu lediglich Pfade zu Inhalten.
Wofür brauchst du eigentlich virtuelle Ordner, kannst du da was ablegen, so wie in echten Verzeichnissen? Wenn ja, wie und wo werden diese Daten gespeichert?

બાય

[hotti]

Moin,

In jedem Fall hat jeder meiner URLs ein Attribut isa=folder wenn es sich um einen Folder (virtuellen Ordner) handelt, das isa-Attribut ist nach außen hin nicht sichtbar und macht zum Anderen den Aufbau einer Hierarchie unabhängig vom URL

Warum einfach, wenn man's sich schwer machen kann?  ;)

Genau ;)
Es sind gerade die Attribute einer Unterseite, wo das Alles zusammen so einfach machen. Meine Unterseiten haben .html aus zwei Gründen:

1. Ich erstelle eine Unterseite.html lokal mit TextPad, da wird der Syntax hervorgehoben
2. Jede Unterseite bekommt das Attribut url=/dateiname.html automatisch, es sei denn, ich vergebe url=/anderer_name dann wird das url-Attribut damit überschrieben.

Alle Unterseiten liegen lokal in einem Verzeichnis, so ist auch der Dateiname eindeutig. Die Attribute sind als HTML-Kommentar eingebaut, die Datei wird einem Webservice-Client übergeben, der parst die Datei, Attribute samt Body ergeben einen Hash, die HTML-Kommentare werden entfernt und der Hash (Array) geht, strukturiert und serialisiert, per HTTP zum Server. Dieser Webservice haut die zukünftige Ressource entweder in die Objekts-Datei oder in MySQL ein. Das Alles gleich aus dem TexPad heraus, Seite erstellen, [Strg][3] und sie ist online.

Darüber hinaus gibt es eine Backend-Lösung, da werden die Inhalte im Browser editiert.

Ich denke nicht in Ordnern, dass ist wohl das Problem.

Denke abstrakt ;)

Für mich sind Links in einem Menu lediglich Pfade zu Inhalten.

Das ist bei mir genauso. Abstrakt: Ein virtueller Ordner ist, genau wie jede Unterseite ein URL mit Attributen wie title, descr, jedoch ohne body-Attribute, aber mit einem Attribut, was den virtuellen Ordner als Ordner kennzeichnet (isa=folder).

Sitemap, Menu, Breadcrumb, das geht dann alles automatisch übers Framework.

Wofür brauchst du eigentlich virtuelle Ordner, kannst du da was ablegen, so wie in echten Verzeichnissen? Wenn ja, wie und wo werden diese Daten gespeichert?

Ein virtueller Ordner ist nur ein Eintrag in der Haupt-Konfigurationsdatei. Beispiel:

[/kissen]
 short=Kissen
 title=Romantische Landhaus-Kissen
 descr=Stuhlkissen, Sofakissen, Kissen für Schlafzimmer, Küche und Wohnzimmer in Handarbeit gefertigt.
 isa=folder
 class=Folder
 parent=/shabbychic

Unterseiten liegen derzeit in einer Objekt-Datei, alle zusammen als Binary serialisiert. Haupt-Konfigurationsdatei und ein Teil der Objekt-Datei (nur die Route, die sich aus dem Request ergibt) werden vom Bootstrap (das ist das Framework-CGI, die main) jeweils zu Hashes deserialisiert, die dann gemischt werden. Komplett im RAM liegt jedoch nur die Haupt-Konfigurationsdatei, somit hat der Singleton Zugriff auf alle Attribute, die gebraucht werden für die Navigation, Sitemap, Breadcrumb usw. Bis dahin spielt sich alles ohne URL-Parameter ab.

Naja, in einer Sitemap erwartet man alle Seiten,

Google empfiehlt _zwei_ Sitemaps, eines für die Suchmaschine und eines für den Besucher. War schon immer so ;)

Horst

[Malcolm Beck´s]

હેલો

[/kissen]
short=Kissen
title=Romantische Landhaus-Kissen
descr=Stuhlkissen, Sofakissen, Kissen für Schlafzimmer, Küche und Wohnzimmer in Handarbeit gefertigt.
isa=folder
class=Folder
parent=/shabbychic

Werden diese Daten in einer Datei gespeichert? Wofür dann MySQL?

Naja, in einer Sitemap erwartet man alle Seiten,

Google empfiehlt _zwei_ Sitemaps, eines für die Suchmaschine und eines für den Besucher. War schon immer so ;)

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.

બાય

[hotti]

hi,

[/kissen]
short=Kissen
title=Romantische Landhaus-Kissen
descr=Stuhlkissen, Sofakissen, Kissen für Schlafzimmer, Küche und Wohnzimmer in Handarbeit gefertigt.
isa=folder
class=Folder
parent=/shabbychic

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 ;)

Bei einem Request auf /foo wird nur dass, was zu /foo gehört aus MySQL gelesen. Aber auch das geht nicht als Extrawurst, sondern wird mit dem Hash aus der ini gemischt und landet zusammen in $self->{BIN} wobei $self der Singleton ist. Das ergibt am Ende einheitliche Prozesse, so z.B. für den Titel einer Response-Seite mit

$self->eav('title' [, 'neuer Title']); # EAV: Entity Attribute Value

das wird dann automatisch ins Template gesetzt.

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.

Horst

[Malcolm Beck´s]

હેલો

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.

બાય

[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

[Malcolm Beck´s]

હેલો

Es gibt noch die Breadcrumb-Geschichte,

Die hab ich auch, der Rest von dir ist mir zu Hoch. Menu, Sitemap und Breadcrumbs haben bei mir zusammengenommen vielleicht 200 Zeilen Code bei 3 Feldern in der DB (gibt natürlich mehr Felder, aber die funktionalität ist mit 3 gegeben: id|name|parent).

બાય

[hotti]

hi,

Es gibt noch die Breadcrumb-Geschichte,

Die hab ich auch, der Rest von dir ist mir zu Hoch. Menu, Sitemap und Breadcrumbs haben bei mir zusammengenommen vielleicht 200 Zeilen Code

Bei mir ist der breadcrumb derzeit ein Attribut: 0 Zeilen Code zum Erzeugen, jedoch 2..3 Zeilen zum Einbauen.

bei 3 Feldern in der DB (gibt natürlich mehr Felder, aber die funktionalität ist mit 3 gegeben: id|name|parent).

Stichwort parent. Coole Mucke, sind wir uns einig ;)

Ja, freilich, hört sich alle bischen kompliziert an, was ich Dir so schreibe, was ich auch gerne mache, weil wir uns schon länger kennen.

So richtig kompliziert waren jedoch nur die Anfänge meines FW. Viele haben unter einem FW möglicherweise eine falsche Vorstellung, vermuten zigtausende Zeilen Code und tausende Mitarbeiter. Der Trend meiner Entwicklung geht jedoch eindeutig in Richtung '(immer) weniger Code macht mehr'. Zentralisierte und abstrakte Datenhaltung ist Bestandteil in diesem Trend, der immer auch in Richtung Perfomance gedacht wird. In meiner Karlsruher Zeit habe ich ein riesen Intranet aufgebaut was eine standortübergreifende Zusammenarbeit ermöglichte auf weit mehr als 300 Unterseiten zusammen mit interaktiven Anwendungen. Oftmals denke ich daran und daran, dass ich vieles, wenn nicht sogar Alles an diesem Patchwork heute anders, besser gesagt, in einer sehr viel kürzeren Zeit erledigt hätte, wenn mir damals mein heutiges FW zur Verfügung gestanden hättte. Entscheidend ist aber nicht der wehmütige Blick in die Vergangenheit, sondern das Lernen aus Fehlern (auch aus denen der Anderen) und Verarbeiten von Erfahrungen.

Jede Anwendung war damals ein extra CGI-Script und handverlinkt, heute habe ich nur noch ein CGI-Script, Anwendungen sind nur noch Klassen und die Verlinkung steht einzig auf einer Parent-Beziehung. Und es hängen ein paar Nebenentwicklungen dran, die im produktiven Umfeld niemals entstanden wären, weil ganz einfach die Zeit dafür nicht da ist, Erfahrungen, die ich auch in anderen Firmen gemacht habe...

Viele Grüße, Horst Alias, Name geändert ;)

[hotti]

(hai)હેલો

Es gibt noch die Breadcrumb-Geschichte,

[] der Rest von dir ist mir zu Hoch. Menu,

Der Vollständigkeit halber, nicht dass ich hier blogge, wir haben ein interessantes Gespräch, zunächst ein schönes Stück Code betr. Breadcrumb:

  
    foreach my $em(@{$self->{MENU}}){  
        push @{$stash{menu}}, {  
            linkname => $self->{BIN}{$em}{short} || $self->{DBF}->eav_hunt($em)->{short} || 'NA',  
            href     => $em ne $ENV{REQUEST_URI} ? qq(href="$em") : '',  
            active   => $em eq $ENV{REQUEST_URI} ? 1 : 0,  
            descr    => $self->{BIN}{$em}{descr} || $self->{DBF}->eav_hunt($em)->{descr},  
        };  
    }  

Schön ja, aber schlecht organisiert, ich schrieb da was von Extrawürsten, Du siehst diese an der Zuweisung für linkname und descr. Da wird einmal in die BIN gegriffen und wenn da der Wert fehlt, wird er mit $self->{DBF} aus der Objekts-Datei nachgeladen. D.h., der Datenfluss ist hier inkonsistent, der wäre so zu konsolidieren, dass ALLE Methoden, welche auf im Request beteiligte Attribute zugreifen, dies NUR über $self->{BIN} tun sollten. Der Code ist dann einfacher zu pflegen.

Die Lösung liegt schon parat:

%{$self->{BIN}} = (%{$self->{BIN}}, %breadcrumbs);

Wobei der hash %breadcrumbs vorher am Stück ermittelt wird über eine Liste der URLs, welche den Breadcrumb ergeben sollen. Über den Data-Abstraction-Layer (persistent Objects, egal an welchem Speicherort, MySQL oder Datei...) wir die Routing-Table dann nur noch an zwei Stellen im Code zusammengebaut, ein etwaiger Austausch des DAL wird weiter vereinfacht, aber darüber denke ich erst nach, wenn es mehr als 1000 Unterseiten sind ;)

Gute Nacht ;)

[hotti]

hi,

Wir waren bei rund 300. Dem User kann und sollte man immer alle vorhalten, aber schön.

Ok, ich nehme Deinen Tipp endlich an und setze den mal so um, guckst Du bitte hier.

Viele Grüße,
Horst Hansel, Brotkrümelfresser

PS, nochn bischen Technik, Selbstgespräch:

Breadcrumb=/foo /bar /boo

braucht in $self->{BIN} die Attribute

short
    descr

für die beteiligten URLs /foo /bar /boo. Derzeit sind die in der Hauptkonfigurationsdatei hinterlegt und somit immer in $self->{BIN}.

To Do: Die EAVs für /foo /bar /boo sollen aus Hauptkonfigurationsdatei raus, weil die nicht für jeden Request gebraucht werden, Ziel: kleinere Routingtable.

Lösung: Die EAVs für /foo /bar /boo werden nur hinzugeladen, wenn der Breadcrumb gefragt ist. Wir brauchen also eine Abfrage auf die Objekt-Datei oder MySQl. Das Resultat wird ein Hash, nennen wir ihn %breadcrumb.

Merge:
%{$self->{BIN}} = (%{$self->{BIN}}, %breadcrumb); # einmal hin, alles drin

War das kompliziert? Ne, is nur Perl ;)

[Malcolm Beck´s]

હેલો

für die beteiligten URLs /foo /bar /boo. Derzeit sind die in der Hauptkonfigurationsdatei hinterlegt und somit immer in $self->{BIN}.

Mit einer rückwärtssuche habe ich es gelöst.

bei „/foo/bar/boo“ wird nach „boo“ und möglichen Parents in der DB gesucht. Wenn Parent „bar“ existiert, weiter nach möglichen Parents von „bar“ suchen. Nebenher speichere ich die Ergebnisse in einem Array, dass ich für die Breadcrumbs nutzen kann. So kann ich auch noch die Inhalte für die aufgerufene URL eindeutig identifizieren. Alles in einem rutsch.

બાય

[hotti]

hi Malcolm,

für die beteiligten URLs /foo /bar /boo. Derzeit sind die in der Hauptkonfigurationsdatei hinterlegt und somit immer in $self->{BIN}.

Mit einer rückwärtssuche habe ich es gelöst.

Backpointer-Patterns ;)

bei „/foo/bar/boo“ wird nach „boo“ und möglichen Parents in der DB gesucht. Wenn Parent „bar“ existiert, weiter nach möglichen Parents von „bar“ suchen. Nebenher speichere ich die Ergebnisse in einem Array, dass ich für die Breadcrumbs nutzen kann. So kann ich auch noch die Inhalte für die aufgerufene URL eindeutig identifizieren. Alles in einem rutsch.

Men at work ;)

Bis dann!

[Malcolm Beck´s]

હેલો

Ok, ich nehme Deinen Tipp endlich an und setze den mal so um, guckst Du bitte hier.

Sieht doch gleich viel besser aus :) Und Suchmaschinen werden sich auch freuen.

બાય