xm22

Nachdem ich vor einigen Threads wieder auf das PAC-Thema gekommen bin, habe ich begonnen, ein Framework, mit dem man an dieses Pattern angelehnte Anwendungen erstellen kann.

Im Grunde ist auch kein Problem. Es gibt sog. Agenten, die jeweils eine Art MVC-Applikation darstellen. Jeder Agent kann wiederum weitere Agenten einbinden.

Man kann sich das so vorstellen:
Es gibt einen "Root"-Agenten, der den Rahmen für die angeforderte Seite darstellt. Dieser kann Agenten einbinden, z. B. ein Login-Formular, eine Liste von Einträgen o. ä.. Diese Liste wiederum kann weitere Agenten einbinden, z. B. ein Formular zum Erstellen neuer Einträge usw. usw..

Diese Agenten sind in einer Verzeichnisstruktur abgebildet.

Jetzt grüble ich bereits einige Tage über ein passendes URL-Design, da man ja einerseits Agentenketten abbilden können soll.

Bis jetzt bin ich zu diesem Schluss gekommen (Es geht nur um das Ansprechen der Agenten, nicht um irgendwelche Parameter, die diese außerdem benötigen:

umgeschriebene URLs:

Direktes ansprechen eines Agenten:
http://localhost/de/Agent/

Kette von Agenten (Agent1 ruft Agent2 auf), Agent2 ruft Agent3 auf:
http://localhost/de/Agent1,Agent2,Agent3/

Mehrere Agenten(-ketten):
http://localhost/de/Agent1,Agent2;Agent4,Agent5;Agent6/

Das ist natürlich sehr kompliziert und die Agentenketten sind auf den Obersten Agenten beschränkt. Fällt einem dazu etwas besseres ein?

Oder nur eine Agentenkette ermöglichen, dann müssen die Agenten halt differenziert genug sein, um die Applikation abbilden zu können..

Mister Ad

dr.e.

Hallo xm22,

ich kann dir hierzu nur den Thread Erweiteres MVC-Controlling (erweitertes Controlling (MVC)) and Herz legen. Ob du nun PAC oder HMVC betrachtest ist nicht allzuviel Unterschied. Insbesondere zum Thema URL-Layout findest du auch einige Anmerkungen.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

xm22

Das habe ich mir auch bereits angesehen. Das Grundprinzip ist ja, dass man ein Dokument "aufruft", das sowohl Unterelemente als auch Oberelemente (Layout) haben kann.

Habe ich das richtig verstanden? Wenn ja, dann ist mein (gewünschter) Ansatz, dass man immer das Oberelement (Root) mit entsprechenden Parametern aufruft, was dazu führt, dass dieses die GUI zusammen baut. Aber das führt, wie Du schon beschrieben hast, zu einer immer komplexeren URL. Daher suche ich eine Möglichkeit das irgendwie anders zu machen..

EDIT: Vor allem, ohne dass Double-Content entsteht..

Ich hatte schon damit geliebäugelt, immer den aktuellen Zustand der Applikation pro Session zu speichern, aber das ist mir zu hanebüchen und 2. kommt damit zwangsweise Double-Content zustande, abgesehen davon, dass die Seite nicht mehr richtig gespidert werden kann.

xm22

Nach langem Suchen scheint es dafür keine Lösung zu geben, weil sich dieses Konzept in meiner Form nicht auf Web-Applikationen übertragen lässt. Das wäre ja echt schade...

dr.e.

Hallo xm22,

du hast vermutlich den verlinkten Thread nicht gründlich genug gelesen. Dort habe ich zwei Ansätze erläutert: Session und URL-Codierung mit und ohne Session. Lies nochmal nach...

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

xm22

Ah - Jetzt habe ich es verstanden - Denke ich. Allerdings widersprichst Du Dir an zwei Stellen (Oder ist das nicht als Widerspruch zu sehen?):
Stelle 1:
Stelle 2:
Aber gut - Das kann man halten wie ein Dachdecker..

Da es anscheinend nicht so verkehrt ist, habe ich mir das URL-Design jetzt so überlegt:

Entweder mit Schlüsseln (var...)
Oder ohne (Um Zeichen zu sparen)
Dazu kommt der Router, der die URLs zusammensetzt bzw. auseinander baut.

Jetzt bin ich noch am Überlegen, ob jeder Agent beim Instanziieren dem Router sagen kann, ob er bestimmte Parameter auf jeden Fall in jede generierte URL packen soll oder nicht. Allerdings könnte das wieder dazu führen, dass eine URL Parameter enthält, die vielleicht gar nicht notwendig sind, weil beim neuen Aufruf der Agent gar nicht benutzt wird.

In der Session will ich keine Zustandsparameter speichern, um Suchmaschinen genauso wie Browser-Controls korrekt bedienen zu können.

Alles sehr kompliziert...

robo47

Wenn dir Suchmaschinen wichtig sind solltest du dir auch was überlegen wie du beim erstellen der url die parameter "sortierst" dass durch verschiedene pfade zum gleichen ziel nicht verschiedene urls zusammenkommen:

z.b.:
http://localhost/agent1;value1,value...value1,value2/...

vs

http://localhost/agent2;value2,value...value1,value2/...

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

xm22

Das hatte ich mir auch schon überlegt und bin bis dato zu dem Ansatz gekommen, die Parameter alphabetisch anzuordnen.

dr.e.

Hi xm22,

Nein, ich sehe an deinen Aussagen, dass du das noch nicht verstanden hast. -> Nochmal in aller Ausführlichkeit lesen und versuchen nachzuvollziehen.

Der von dir beschrieben Ansatz ist weiter nicht besser als der, denn ich mit dem Nomen "Wahnsinn" beschrieben habe, denn du schaffst es damit nicht die Komplexität des HMVC-DOM-Baums verstecken kannst!

Lies dir bitte das verlinkte Thema nochmal durch und schau dir parallel mal das APF an. Das unterstützt dich out-of-the-box mit einer generischen Page-Controller-Architektur, in die du eine Software nur noch betten musst.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

xm22

Ich versuche mal, es so wiederzugeben, wie ich es aufgefasst habe (Für das APF). Wenn das falsch ist, würde ich mich freuen, wenn Du das richtig stellen kannst:

Man hat den Page-Controller, der durch (ineinander verschachtelte Taglibs) einen DOM-Baum aufbauen kann, wobei die Taglibs das ungefähre Gegenstück zu meinen Agenten darstellen. Jede Taglib, bzw. das, was dahinter steht, wird durch die URL bzw. Zustandsdaten in der Session gesteuert, wodurch es möglich ist, durch die URLs keine Rückschlüsse auf den Zustand der Applikation ziehen zu können und die Informationen in den URLs minimal halten zu können.


EDIT: Um Missverständnisse zu vermeiden: Natürlich werden in der URL nur Parameter für Agenten übergeben, die diese auch benötigen, d. h. ein Login-Formular benötigt keine Parameter, also taucht dieser Agent in der URL auch nicht auf. Anders z. B. eine Liste mit irgendwas, wo z. B. die Sortier-Parameter gegeben sein müssen. Genauso das Einbinden von Agenten in Agenten. Wenn ein Agent von sich aus ableiten kann, was er einbinden kann/muss, dann muss das natürlich nicht über die URL gesteuert werden.