Dynamisch generierte Navigation (MVC)
MB
- php
- programmiertechnik
Moin Community,
was wäre es am günstigsten mit einer MVC Aritechtur, dynamisch generiertes navigation der Webseite Applikation zu erstellen? Als greenhorn würde ich mich für die controller einer seite in der Appikation entscheiden. den die existieren nur einmal pro seite. Anders ist das bei Datenbanken.
vlg MB
Moin Community,
was wäre es am günstigsten mit einer MVC Aritechtur, dynamisch generiertes navigation der Webseite Applikation zu erstellen?
Mit einer gut durchdachten Konfiguration, die sowohl händisch editierbar als auch maschinenlesbar ist (.ini) ergibt sich auch eine dynamische Navigation. Der Trick zur Hierarchie: Zu jedem URL wird eine Eigenschaft parent= konfiguriert. Akuelles Beispiel:
[/kalender]
title=Rund um unsere Kalender
descr=Ein Kalender ist der Versuch, einen ganzzahligen Zusammenhang zwischen Jahr und Tag herzustellen...
isa=folder
class=Folder
parent=/hobby.html
breadcrumb=/kalender
short=Kalender
[/advent.html]
class=Advent
title=Adventskalender 2016 Online
descr=Vierundzwanzig kleine Überraschungen warten auf Ihren Klick
parent=/kalender
no_cache=1
no_simlinks=1
bodyclass=class='advent'
Und der Parent mit class=Folder sammelt bei jedem Request seine Kinderchen ein und stellt die in einer <dl> zum Rausklicken dar. Das kann dann auch beliebig verschachtelt werden...
Fertig; (und ohnr Brille geporsted!)
Hallo pl,
Mit einer gut durchdachten Konfiguration, die sowohl händisch editierbar als auch maschinenlesbar ist (.ini) ergibt sich auch eine dynamische Navigation.
Auch bei MVC, PHP und klassenbasierend? Ich arbeite mit genau dem.
Ich hab noch nie mit INI gearbeitet weil ich es nicht für nötig gehalten habe, habs aber gewollt. Das mit parsen ist denke ich eher umständlich und ich nehme mal an, das man mit statischen Klassen die man nicht instanziieren muss, besser bedient ist. Mit fehlt aber leider die Praxis Erfahrung wie aber du sie hast ;-).
Zu meiner Frage. Ich glaube das deine AW sowas wie die Seiten Controller in PHP MVC sind die man nur registrieren muss (ich denke vergleichbar mit deinem INI) und schwupps hat man ne navi mit referenzen. Also meine Annahme. Bitte, Bitte, Bitta korrigiere mich wenn ich das was falsch verstanden habe.
vlg MB
Zu meiner Frage. Ich glaube das deine AW sowas wie die Seiten Controller in PHP MVC sind die man nur registrieren muss (ich denke vergleichbar mit deinem INI) und schwupps hat man ne navi mit referenzen. Also meine Annahme. Bitte, Bitte, Bitta korrigiere mich wenn ich das was falsch verstanden habe.
Also: Der Request kommt rein und wird auf ein Script umgeschossen mit mod_rewrite. Ds Script findet in $ENV{REDIRECT_URL} z.B. /advent.html. Nun guckt das Script in die .ini und findet alle Attribute/Eigenschaften zu diesem URL und natürlich auch die Klasse class=Advent -- diese Klasse wird kompiliert(include, require) und eine Instanz wird erstellt.
Dieser Instanz stehen dann alle Methoden zur Verfügung die es braucht, die gewünschte Response zu erstellen -- mit oder ohne Parameter im Request auf diesen URL. Natürlich weiß auch die Instanz, wo hierfür das Template zu holen ist (in PHP wäre das ein weiteres include // require).
Und die Instanz weiß, was ans Menu gepappt werden muss: Nämlich der für /advent.html konfigurierte parent=/kalender und so ergibt sich die Navigation bzw. Breadcrumb.
Und wenns per Konfig nicht ausgeschaltet ist, wird auf der Reponse-Seite eine Liste eingebaut zu allen anderen im gleichen parent=/kalender liegenden Anwendungen (wenns auch die Bildschirmbreite hergibt).
Das ist der Ablauf bei jedem Request, da wird nur das kompiliert was zum URL konfiguriert ist. Für andere URLs ist ggf. eine andere Klasse konfiguriert aber die aufzurufenden Methoden sind namentlich immer diegleichen. class=HTMLfile holt das Template z.B. aus dem in zum URL konfigurierten file= Attribut.
Die .ini ist gleichzeitig die Projektverwaltung, die Routing-Table und die Konfiguration. Ich hab das vor 15 Jahren so entwickelt, schon immer objektorientiert und jahrelang bewährt.
nabend pl,
als leihe würde ich mal sagen sehr gute technik. Ich bin dabei Informationen einzuholen wie es die Meister gemacht haben. Dafür herzlichen Dank :-).
Die .ini ist gleichzeitig die Projektverwaltung, die Routing-Table und die Konfiguration. Ich hab das vor 15 Jahren so entwickelt, schon immer objektorientiert und jahrelang bewährt.
Ich kenne mich wenig bis überhaupt nicht mit Perl aus und dass das eine OOP Sprache ist. Du arbeitest nehme ich an vorrangig mit Perl. Ich hätte mich besser über Perl informieren müssen :/.
vlg MB
Irgendwie muss ja eine Konfiguration auf den Server kommen, das hat mit Perl gar nichts zu tun und wer'sich antun will, nehme statt INI => XML oder JSON oder YAML oder baue sich ein farbiges Backend...
Deployed wird sowieso keines der o.g. Dateiformate ;)
Irgendwie muss ja eine Konfiguration auf den Server kommen, das hat mit Perl gar nichts zu tun und wer'sich antun will, nehme statt INI => XML oder JSON oder YAML oder baue sich ein farbiges Backend...
Deployed wird sowieso keines der o.g. Dateiformate ;)
das siehst du mal was für ein neulig ich noch bin :D.
vlg MB
Irgendwie muss ja eine Konfiguration auf den Server kommen, das hat mit Perl gar nichts zu tun und wer'sich antun will, nehme statt INI => XML oder JSON oder YAML oder baue sich ein farbiges Backend...
Deployed wird sowieso keines der o.g. Dateiformate ;)
das siehst du mal was für ein neulig ich noch bin :D.
Kein Problem, jeder fängt mal ganz klein an. So muss ein Index aussehen, und wenn eine neue Ressource hinzukommt, werden die Attribute einfach in die lokale Datei eingetragen, samt Inhalt
<!-- title=Der Kötsch wird auch Kaitsch genannt -->
<!-- descr=Es ist der wohl schönste Aussichtsberg im Landkreis Weimar -->
<!-- parent=/heimatliches -->
<p> Der Name leitet sich ab von Katsch, was aus dem Slawischen ...
und per Webservice geht die Datei über die RPC-Scnittstelle auf zum Server wo /berg.html im virtuellen Ordner /heimatliches landet. Dieser Vorgang ist nur ein Shortcut [Strg][3], direkt aus dem Editor heraus wird der RPC-Call ausgelöst. Die Ordnerstruktur ist rein virtuell und hat mit dem Dateisystem gar nichts zu tun, was den Vorteil hat, dass bei einem etwaigen Umzug in einen anderen virtuellen Ordner der URL erhalten bleibt.
Dynamische Inhalte: Der Webressource wird ein Interface zugewiesen:
<!-- interface=date -->
und schon kann über einen Platzhalter das aktuelle Datum oder ein Monatskalender eingebaut werden. Interaktive Seiten bzw. Anwendungen:
<!-- interface=feedback -->
hängt ein Feedbackformular unten an die Seite. Für tote HTML-Seiten kann die Template-Engine ausgeschaltet werden
<!-- no_tt=1 -->
und der Last-Modified-Header wird nicht gesendet, wenn
<!-- no_cache=1 -->
gesetzt ist. Du siehst also, das ist OOP in der Praxis, also nix Runkeln und Kartoffeln sondern eine Sache die jeden Anwender und Programmierer begeistern wird. Das interface= Attribut entspricht dem C im MVC aber letztendlich isses doch egal nach welchem Muster die Seite gebaut ist.
Ich kenne Perl-Spezialisten die diskutieren stundenlang den Unterschied zwischen Liste und Array aber um ehrlich zu sin, dass war mir schon immer scheißegal. Wichtig ist es, damit umgehen zu können, auch wenns mal länger dauert: An meinem Konzept "Alternative zu CGI.pm" hab ich beispielsweise über ein Jahr lang gearbeitet und damit meine ich nicht die 100 Zeilen Code zu tippen, sondern Überlegungen um aus dem stickigen Perl/CGI.pm Mief rauszukommen.
Und stets bestehen Ergebnisse von Programmierern nicht etwa aus ein paar tausend Zeilen Code sondern auch aus weiterhin gelebten komplexen Denkvorgängen mit ungezählten Nebenrechnungen und Recherchen -- kein Arbeitgeber der Welt kann sowas jemals bezahlen (Programmierer-Gehälter sind sowieso Betrug).
Schönes Wochenende!
Hallo und guten Tag,
wie wäre es am günstigsten, mit einer MVC Aritechtur, eine dynamisch generierte Navigation der Webseiten zu erstellen?
Da kommen doch zunächst erstmal diverse Fragen auf:
Es gibt mNm kein allgemeingültiges System. Darum blasen sich CMS bei der Entwicklung auch immer relativ schnell auf und kommen schon nach wenigen Denkschritten nicht mehr ohne Datenbank aus.
Ich dachte daher schon oft, dass man für kleine Webentwicklungen einfach nur jede Seite einzeln aufbauen sollte und jeweils die Links auf die relevanten anderen Seiten einsetzen sollte. Um eine Übersicht zu bekommen, kann man dann eine Funktion über alle Seiten laufen lassen, die eine Sitemap mit allen internen (ohne Scheme und Domainangabe) und allen externen Links (mit Scheme und Domainangabe) erstellt, nach Linktexten alphabetisch sortiert usw.
So eine Funktion könnte sicherlich ein nettes Schmankerl für unsere PHP-Abteilung im Wiki sein. Ich nehm' das mal auf meinen Zettel (-> ToDo-Liste).
Einen Schritt weitergedacht, könnte man nun noch für die Links eine Darstellungsfunktion erstellen, die vorher prüft, ob der Link noch erreichbar ist, bevor sie ihn ins Dokument einsetzt. Auch das könnte eine nettes Schmankerl sein (-> ToDo-Liste) :-)
Grüße
TS
Hallo TS,
ich möchte einfach seiten referenz ohne zusätze wie gästebuch\post\1232 sondern einfach nur gästebuch ohne restriktion der Zugriffsbeschränkung.
vlg MB
Tach!
was wäre es am günstigsten mit einer MVC Aritechtur, dynamisch generiertes navigation der Webseite Applikation zu erstellen?
Was verstehst du unter einer dynamisch generierten Navigation?
Als greenhorn würde ich mich für die controller einer seite in der Appikation entscheiden. den die existieren nur einmal pro seite. Anders ist das bei Datenbanken.
Wie das bei dir in der Anwendung ist, muss nicht zwangsläufig in anderen Anwendungen genauso sein. Es ist auch nicht so, dass für einen Request nur ein Controller die Antwort erzeugen darf. Für jede Komponente der Seite kann auch ein jeweils eigenes Triplet aus M, V und C zuständig sein.
dedlfix.
was wäre es am günstigsten mit einer MVC Aritechtur, dynamisch generiertes navigation der Webseite Applikation zu erstellen?
Was verstehst du unter einer dynamisch generierten Navigation?
z.B. eine klasse page.controller die ein Verzeichnis controllers ausliest, spezifischen substring '.controller.php' der Dateien im Verzeichnis such und gefundene Dateien eine referenz anlegt [ 'home' => '/home/' ] und im view als navigation in HTML übergeben wird. der Absolutepfad: c:\xampp\htdocs[website]\app\controllers\home.controller.php habe ich gemacht aber vor einem jahr.
Als greenhorn würde ich mich für die controller einer seite in der Appikation entscheiden. den die existieren nur einmal pro seite. Anders ist das bei Datenbanken.
Wie das bei dir in der Anwendung ist, muss nicht zwangsläufig in anderen Anwendungen genauso sein.
ja sry natürlich. Ich dachte das wäre klar.
Es ist auch nicht so, dass für einen Request nur ein Controller die Antwort erzeugen darf. Für jede Komponente der Seite kann auch ein jeweils eigenes Triplet aus M, V und C zuständig sein.
Ist mir bewusst aber ich habe keinerleih Praxiserfahrung mit verschachtelten MVCs und Überhaupt. Wie sehen solche Verschlachtelungen aus und kannst du mir n anwendungsbeispel geben?
vlg MB
Tach!
was wäre es am günstigsten mit einer MVC Aritechtur, dynamisch generiertes navigation der Webseite Applikation zu erstellen?
Was verstehst du unter einer dynamisch generierten Navigation?
z.B. eine klasse page.controller die ein Verzeichnis controllers ausliest, spezifischen substring '.controller.php' der Dateien im Verzeichnis such und gefundene Dateien eine referenz anlegt [ 'home' => '/home/' ] und im view als navigation in HTML übergeben wird. der Absolutepfad: c:\xampp\htdocs[website]\app\controllers\home.controller.php habe ich gemacht aber vor einem jahr.
Du erstellst also von allen Controllern einen Menüeintrag. Kann man machen. Aber ist das sinnvoll? Na gut, anscheinend passt das bisher zu deinem Konzept. Mir wäre das vermutlich zu unflexibel. Da erscheinen alle Einträge in alphabetischer oder beliebiger Reihenfolge im Menü. Sortierung nach Themengebieten ginge dann nur mit einem Sortierkriterium im Controller. Aber warum muss der Controller wissen, an welcher Stelle im Menü er auftauchen soll? Nein, so würde ich das nicht haben wollen. Das Menü würde ich per Hand erstellen oer irgendwo konfigurieren, was in welcher Reihenfolge erscheinen soll. Aber wenn dir dein System so zusagt, wie es ist, dann ist es auch gut.
Ist mir bewusst aber ich habe keinerleih Praxiserfahrung mit verschachtelten MVCs und Überhaupt. Wie sehen solche Verschlachtelungen aus und kannst du mir n anwendungsbeispel geben?
Eigentlich ganz einfach. Üblicherweise wird ein Controller instantiiert und von dem eine Action aufgerufen. Der Rückgabewert ist eine gerenderte View, oder eine Referenz auf eine View, die bereits alle Daten hat, um ein Ergebnis erzeugen zu können, wenn sie die Anforderung zu rendern bekommt. Und das kann man nun mit weiteren Controllern und deren Actions veranstalten. Man hat dann also beispielsweise ein gerendertes Menü und fügt das in das nav-Element ein und einen gerenderten Hauptinhalt, und der kommt ins main.
dedlfix.
Aber warum muss der Controller wissen, an welcher Stelle im Menü er auftauchen soll? Nein, so würde ich das nicht haben wollen. Das Menü würde ich per Hand erstellen oer irgendwo konfigurieren, was in welcher Reihenfolge erscheinen soll.
hmm da hast du recht und pl ist der selben auffassung wenn ich richtig verstanden habe. Klingt sinnig.
vlg MB
Moin dedlfix, ist mir beim grübeln eingefallen:
Du erstellst also von allen Controllern einen Menüeintrag. Kann man machen. Aber ist das sinnvoll?
möglich wäre ein priorisierung mit Array Index. Aber wie du sagtest, ein konzept art. Ich denke mir von fall zu fall ist der grad der nützlichkeit sehr gering. Es ist aber ja auch nur um meine Fähigkeiten zu schulen. Mich würde interessieren wie weit dieses Konzept in der Realen welt Vertreten ist.
vlg MB