nicht angemeldet
Standortanzeige
0 
Der Martin
0
Standortanzeige
Hallo,
in einigen Homepages wird in einer Zeile angezeigt, wo man sich gerade befindet - z.B:
Home -> Lebenslauf -> Schule -> Zeit im Gymansium
oder so ähnlich. Also nach jedem Klick auf einen Link wird der "Weg" bzw. Pfad erweitert und angezeigt.
Gut daran ist, dass man damit auch wieder 2 oder 3 Schritte zurückgehen kann.
Geht sowas unter PHP bzw. wir kriege ich das überhaupt geregelt?
Habe schon gegoogelt, aber nichts genaues gefunden.
Danke,
Helmut
-
Hi,
in einigen Homepages wird in einer Zeile angezeigt, wo man sich gerade befindet - z.B:
Home -> Lebenslauf -> Schule -> Zeit im Gymansium
oder so ähnlich.ja, nennt sich "Breadcrumb trail" oder "Breadcrumb navigation".
Geht sowas unter PHP bzw. wir kriege ich das überhaupt geregelt?
Natürlich geht das. Du musst nur zu jeder Seite deiner Webpräsenz ihre Position innerhalb der Seitenhierarchie speichern (Fleißarbeit) oder ermitteln (z.B. aus der URL, wenn sie systematisch aufgebaut ist).
So long,
Martin--
Irgendwann in grauer Vorzeit benutzte einer unserer prähistorischen Vorfahren ein Schimpfwort anstelle der Keule.
Die Zivilisation hatte begonnen.
-
hi,
Geht sowas unter PHP bzw. wir kriege ich das überhaupt geregelt?
Mit einer praktikablen Projektverwaltung fängt eine solche Regelung an. Darin sind für jede einzelne Seite, die nach dem Publizieren eine URL bekommt, auch alle anderen Eigenschaften festgehalten, z.B. Title, Beschreibung, Autor... und: Zu welchem Ordner die Seite gehörig ist. Aus Ordner/Unterordner ergibt sich die Navigation.
Viele Grüße,
Horst Hagebau--
Wenn jedes zweite Wort 'saufen' ist, fängt das andere Wort mit 'f' an.-
Morgen Helmut,
Geht sowas unter PHP bzw. wir kriege ich das überhaupt geregelt?
Mit einer praktikablen Projektverwaltung fängt eine solche Regelung an. Darin sind für jede einzelne Seite, die nach dem Publizieren eine URL bekommt, auch alle anderen Eigenschaften festgehalten, z.B. Title, Beschreibung, Autor... und: Zu welchem Ordner die Seite gehörig ist. Aus Ordner/Unterordner ergibt sich die Navigation.das wäre auch mein Ansatz, sich über seine Projektverwaltung Gedanken zu machen. Im idealsten Fall bildet sich die in den Dokumenten einzubettende Navigation auch im Dateisystem ab. Das hat den Vorteil, auch für Suchmaschinen Stichworte im Pfad eines Dokuments, die die Bewertung einer Relevanz steigern kann, benennen zu können (http://www.xy.tld/Lebenslauf/Schule/Zeit_im_Gymansium). Mit PHP müsste bei einem so strukturierten Projekt nur
$_SERVER['REQUEST_URI']mit geeigneten Stringfunktionen analysiert und in Verweise umgewandt werden.Gruß aus Berlin!
eddi-
Morgen Helmut,
moin auch;
das wäre auch mein Ansatz, sich über seine Projektverwaltung Gedanken zu machen. Im idealsten Fall bildet sich die in den Dokumenten einzubettende Navigation auch im Dateisystem ab [..]
Genau! Das FS wäre eine Möglichkeit und ist gut umzusetzen, zum Festhalten der Information "/Pfad/Dateiname" ist das schon ausreichend.
Es gibt, und damit wieder zurück zur Projektverwaltung, natürlich auch die Möglichkeit, alle Attribute losgelöst vom Dateisystem (FS) zu verwalten. Das ist meine (Best) Practice, die ich so lebe. Idealerweise wird sowas dann auch elektronisch festgehalten, z.B. so in einer INI(Text)datei:
[/index.html]
title = Rund um die Hochregaltechnik im Baumarkt
descr = Gabelstabler und weitere Techniken ...
author = Horst Hagebau
lastmod = Fri, 09 Oct 2009 09:00:16 GMT
folder = /usw. Was das Beispiel zeigt: der Pfad kann einmal in der URL selbst und zum Anderen davon unabhängig als Attribut notiert sein. Bei einer konsequenten Umsetzung der objektorientierten Philosophie ist das Attribut auschlaggebend.
Viele Grüße,
Horst Deppendorff -
das wäre auch mein Ansatz, sich über seine Projektverwaltung Gedanken zu machen. Im idealsten Fall bildet sich die in den Dokumenten einzubettende Navigation auch im Dateisystem ab.
Ich bin gegenteiliger Auffassung.
urls sollen transparent gegenüber dem Dateisystem sein.
Wenn du dein Dateisystem umorganisierst, willst du deshalb nicht andere URLs für das Web.
Nicht zuletzt kann die Lage der Ressourcen auf dem Filesystem durch ein Rechtesystem bedingt sein, wohingegen aber der öffentliche Zugang nach Rubriken erfolgt, die nichts mit diesen Rechten zu tun hat.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
hi,
urls sollen transparent gegenüber dem Dateisystem sein.
Das kann ich eigentlich nur faustdick unterstreichen. Es ist j aauch so, dass das FS nicht viel Möglichkeiten bietet, eigene Attribute von Dateien, die letztendlich URLs darstellen, zu speichern.
Also raus mit dem Kram und vom FS unabhängig machen.
/url.html
css =
template =
author =
description =
folder =
lastmod =
title =
etc ...Content Management aus einer objektorientierten Projektverwaltung heraus kann sooooo einfach sein ;-)
Hotti
-
Re:
...Es ist j aauch so, dass das FS nicht viel Möglichkeiten bietet, eigene Attribute von Dateien, die letztendlich URLs darstellen, zu speichern.
Für den allgemeinen Nutzer wird das sicher auf absehbare Zeit noch so bleiben. Dennoch sei auf extended file attributes verwiesen, die derweil von den gängigen *NIX-Systeme unterstützt werden. Auch webübliche Scriptsprachen haben bereits Möglichkeiten integriert: Perl, Python, PHP
Eine entsprechende FTP-Unterstützung lässt aber auf sich warten. So bleibt es Zukunftsmusik. ;(Also raus mit dem Kram und vom FS unabhängig machen.
/url.html
css =
template =
author =
description =
folder =
lastmod =
title =
etc ...Das ist auch wieder so eine Sache, die ich persönlich nicht sonderlich gut finde; zumal es ja tatsächlich andere Möglichkeiten gäbe, die die Merkmale mit den einzelnen Dateien verschmelzen. Jedoch bei angesprochenen Umstrukturierungen ergäbe sich für diese INI-Files-Methode aber auch fürs Arbeiten mit den EFA ein Mehraufwand.
Gruß aus Berlin!
eddi-
hi,
Also raus mit dem Kram und vom FS unabhängig machen.
/url.html
css =
template =
author =
description =
folder =
lastmod =
title =
etc ...Das ist auch wieder so eine Sache, die ich persönlich nicht sonderlich gut finde; zumal es ja tatsächlich andere Möglichkeiten gäbe, die die Merkmale mit den einzelnen Dateien verschmelzen. Jedoch bei angesprochenen Umstrukturierungen ergäbe sich für diese INI-Files-Methode aber auch fürs Arbeiten mit den EFA ein Mehraufwand.
O.g. ini ("Objekte") ist _nicht_ meine Projektverwaltung, sondern das Ergebnis derer (do'nt edit). Sicher gäbe es noch viele andere Möglichkeiten, Attribute von URLs in elektronischer Form festzuhalten, beispielsweise in einer MySQL-DB. Das hängt letztendlich auch von den Möglichkeiten des Providers ab. Vom FS und EFA hab ich mich schon lange verabschiedet, mit meinem ContentManagement bin davon unabhängig und auch sehr flexibel (Scalierbarkeit). Schließlich ist eine Datenquelle "Objects" auch nicht nur auf den "Content-Type: text/html" beschränkt und dient bei mir auch als Datenquelle für rss+xml.
Hotti
-
-
-
Re:
...Im idealsten Fall bildet sich die in den Dokumenten einzubettende Navigation auch im Dateisystem ab.
Ich bin gegenteiliger Auffassung.
urls sollen transparent gegenüber dem Dateisystem sein.Der Meinung bin ich auch:
Lebenslauf/
|
|-Schule/
| |
|-Zeit\_im\_Gymansium | |-Pratika/ | | | |-bal | | |-blu
|
-Ausbildung |bluberWas ist an dieser Verzeichnisstruktur nicht transparent?
Wenn du dein Dateisystem umorganisierst, willst du deshalb nicht andere URLs für das Web.
Ich gehe mal davon aus, dass Du eine Verzeichnisstruktur umorganisieren willst und kein ganzes Dateisystem. Dabei müssten jedenfalls die Verweise in den einzelnen Dokumenten verändert werden. Bildet sich die Struktur jedoch auch im Dateisystem ab, kann das eine Script-Routine selbständig. Dagegen sehe ich für Rolfs INI-File-Methode einen Mehraufwand.
Die Vorteile dieser Transparenz liegen für mich offensichtlich auf der Hand.Nicht zuletzt kann die Lage der Ressourcen auf dem Filesystem durch ein Rechtesystem bedingt sein, wohingegen aber der öffentliche Zugang nach Rubriken erfolgt, die nichts mit diesen Rechten zu tun hat.
Mir ist auch nicht wirklich klar, was Du im Konkreten meinst. Wenn mutmaßlich einer einzelnen Datei die Leserechte für den Webserver entzogen werden, ist dies ein absolutes Hindernis unabhängig der Methode.
Gruß aus Berlin!
eddi-
hi Eddi,
Die Vorteile dieser Transparenz liegen für mich offensichtlich auf der Hand.
Bei einer Änderung der Dir-struktur ändert sich die URL, sofern die Verzeichnisstruktur auf den Webtree abgebildet wurde.
Es ist nicht möglich, alle gewünschten Attribute im FS unterzubringen, zumindest ist diese Möglichkeit sehr begrenzt auch mit EFA (Erweiterten File Attr).
Bei den Webs, die ich so baue, ist das FS kein abstract Layer (URL) sondern nur ein physischer Speicherort für Daten.
Das Verzeichnis /cgi-bin/ ist sowieso schon virtuell.
Hotti
-
Hallo,
hi Eddi,
Die Vorteile dieser Transparenz liegen für mich offensichtlich auf der Hand.
Bei einer Änderung der Dir-struktur ändert sich die URL, sofern die Verzeichnisstruktur auf den Webtree abgebildet wurde.
Das resultiert aus dem Konzept. Es bedeutet nicht mehr, als dass man sich, wie geschrieben, Gedanken über die Struktur seines Projekts macht.
Generell bin ich der Auffassung, es ist erstmal wichtiger mit den absoluten Grundlagen vertraut zu sein bzw. Fragende mit den Grundlagen vertraut zu machen. Dazu gehören für mich Dateisystem, -transfer und Möglichkeiten von Strukturen. Ein CMS ist alles andere als diese Grundlagen. Es benötigt genauso viel Aufwand (im Sinne von Lernstoff) wie die Grundlagen selbst, macht aber darüber hinaus abhängig und begrenzt den Nutzer auf die Möglichkeiten des CMS. Mir widerstrebt dies gegen das SELF.Es ist nicht möglich, alle gewünschten Attribute im FS unterzubringen, zumindest ist diese Möglichkeit sehr begrenzt auch mit EFA (Erweiterten File Attr).
Welche Gerenzen siehst Du, die ich wohl nicht sehe?
Bei den Webs, die ich so baue, ist das FS kein abstract Layer (URL) sondern nur ein physischer Speicherort für Daten. Das Verzeichnis /cgi-bin/ ist sowieso schon virtuell.
Das kann ja möglich sein, ist aber genaugenommen kein Argument gegen eine andere Strukturierung, denn dieses Argument resultiert aus einer Strukturierung. ;)
Gruß aus Berlin!
eddi-
hi Eddi,
Es ist nicht möglich, alle gewünschten Attribute im FS unterzubringen, zumindest ist diese Möglichkeit sehr begrenzt auch mit EFA (Erweiterten File Attr).
Welche Gerenzen siehst Du, die ich wohl nicht sehe?
Hauptsächlich ist das die Plattformabhängigkeit.
Bei den Webs, die ich so baue, ist das FS kein abstract Layer (URL) sondern nur ein physischer Speicherort für Daten. Das Verzeichnis /cgi-bin/ ist sowieso schon virtuell.
Das kann ja möglich sein, ist aber genaugenommen kein Argument gegen eine andere Strukturierung, denn dieses Argument resultiert aus einer Strukturierung. ;)
Freilich ist das kein Argument _gegen_ eine andere Strukturierung, aber ein Argument dafür, die Strukturierung generell virtuell zu machen. Ohne eine solche Abstraktion wäre mein Web mit derzeit über 200 URLs undenkbar für mich, und wahrscheinlich auch nicht mehr fehlerfei machbar, letzeres insbes. hinsichtlich der Verlinkung und der Automatisierung der in diesem Thread angesprochenen BreadCrumbs.
Was den Aufwand der Projektverwaltung betrifft: Für mich undenkbar, mit dem Editor einen Verzeichnisbaum rauf und runterzutanzen. Bei mir ist alles zentral: ein Verzeichnis mit den Bodies, eine Verwaltungsdatei, virtuelle Ordner. Lediglich das virtuelle Verzeichnis /cgi-bin/ deckt sich physikalisch mit dem FS. Auf jeden Fall hat sich mein Überlegungsaufwand gelohnt, Scripts und Module zu schreiben, die es mir jetzt auf Knopfdruck ermöglichen, Inhalte zu publizieren ohne mit der Maus rumzufummeln (FTP, HTTP als Übertragungsprotokolle).
Viele Grüße,
Horst-
Re:
Es ist nicht möglich, alle gewünschten Attribute im FS unterzubringen, zumindest ist diese Möglichkeit sehr begrenzt auch mit EFA (Erweiterten File Attr).
Hauptsächlich ist das die Plattformabhängigkeit.Ach so meinst Du das. Mit EFA gebe ich Dir recht. Jedoch ist das nicht die einzige Möglichkeit, Metadaten an den den Inhalt zu binden. HTML hat das <meta>- bzw. <title>-Element. Dort lassen sich alle Daten plattformunabhängig ablegen. Es ist auch hier eine Frage der Strukturierung. Und auch hier ist es nicht die einzige Möglichkeit alles dynamisch aus Schablonen zu generieren und zu servieren: Caching von Seiten - wann und wie?
Bei den Webs, die ich so baue, ist das FS kein abstract Layer (URL) sondern nur ein physischer Speicherort für Daten. Das Verzeichnis /cgi-bin/ ist sowieso schon virtuell.
Das kann ja möglich sein, ist aber genaugenommen kein Argument gegen eine andere Strukturierung, denn dieses Argument resultiert aus einer Strukturierung. ;)Freilich ist das kein Argument _gegen_ eine andere Strukturierung, aber ein Argument dafür, die Strukturierung generell virtuell zu machen. Ohne eine solche Abstraktion wäre mein Web mit derzeit über 200 URLs undenkbar für mich, und wahrscheinlich auch nicht mehr fehlerfei machbar, letzeres insbes. hinsichtlich der Verlinkung und der Automatisierung der in diesem Thread angesprochenen BreadCrumbs.
Das wiederum verstehe ich nicht. Wenn ich vor einem Web sitze, deren (virtuelle) Struktur für mich über die Adresszeile ja erfahrbar ist, habe ich bei zunehmender Projektgröße eher meine Probleme, wenn diese Struktur des Webs sich nicht im Dateisystem abgebildet ist. (Naja, ich bin da eher Handarbeiter. Vielleicht ist es auch eine Geschmackssache.)
Horst
Was ist Dir eigentlich lieber: Rolf oder Horst?
Gruß aus Berlin!
eddi-
Re:
Reh ;-)
Ach so meinst Du das. Mit EFA gebe ich Dir recht. Jedoch ist das nicht die einzige Möglichkeit, Metadaten an den den Inhalt zu binden. HTML hat das <meta>- bzw. <title>-Element. Dort lassen sich alle Daten plattformunabhängig ablegen.
Richtig. Aber da werden die Daten nicht verwaltet, die Projektverwaltung setzt mindestens auf einen Layer vorher auf und HTML ist das was dabei rauskommt (Presentation Layer in _meinem_ "OSI Referenz Modell").
Das wiederum verstehe ich nicht. Wenn ich vor einem Web sitze, deren (virtuelle) Struktur für mich über die Adresszeile ja erfahrbar ist, habe ich bei zunehmender Projektgröße eher meine Probleme, wenn diese Struktur des Webs sich nicht im Dateisystem abgebildet ist. (Naja, ich bin da eher Handarbeiter. Vielleicht ist es auch eine Geschmackssache.)
Für mich ist die Adresszeile {REQUEST_URI} rein technischer Natur. Btw., in den ersten Versionen von SELFHTML waren die URLs auch alle in einer Verzeichnisebene und die Ordner virtuell. Insofern ist das keine Erfindung von mir. Aber den praktischen Nutzen hab ich sofort erkannt *G*. In Fakt sieht der Besucher HTML im Browserfenster.
Was ist Dir eigentlich lieber: Rolf oder Horst?
Mir doch egal ;-)
Viele Grüße aus KA,
Rolf-
Re:
Ach so meinst Du das. Mit EFA gebe ich Dir recht. Jedoch ist das nicht die einzige Möglichkeit, Metadaten an den den Inhalt zu binden. HTML hat das <meta>- bzw. <title>-Element. Dort lassen sich alle Daten plattformunabhängig ablegen.
Richtig. Aber da werden die Daten nicht verwaltet, die Projektverwaltung setzt mindestens auf einen Layer vorher auf und HTML ist das was dabei rauskommt (Presentation Layer in _meinem_ "OSI Referenz Modell").Ja, nur steht das einer bestimmten Strukturierung weder im Wege noch begünstigt sie eine. Und das meinte ich ja vorhin auch.
Gruß aus Berlin!
eddi-
hi Eddi,
Ach so meinst Du das. Mit EFA gebe ich Dir recht. Jedoch ist das nicht die einzige Möglichkeit, Metadaten an den den Inhalt zu binden. HTML hat das <meta>- bzw. <title>-Element. Dort lassen sich alle Daten plattformunabhängig ablegen.
Richtig. Aber da werden die Daten nicht verwaltet, die Projektverwaltung setzt mindestens auf einen Layer vorher auf und HTML ist das was dabei rauskommt (Presentation Layer in _meinem_ "OSI Referenz Modell").Ja, nur steht das einer bestimmten Strukturierung weder im Wege noch begünstigt sie eine. Und das meinte ich ja vorhin auch.
Achsoja, freilich ,-)
Wenn die (virtuelle)Ordnerstruktur im FS steckt, reichts ja, den REQUEST_URI zu parsen, um daraus die BreadCrumbs zu bauen.
Viele Grüße,
Hans von der Gretl,der Brotrümelspur nun zurück in die Küche folgend...
--
'f' wie Abendessen ;-)
-
-
-
-
-
-
-
-
-
-