Controller inkl. oder exkl. Action

[Gast]

Eigenbau

[MaxC]

Cool. Respekt!

[Gast]

Danke

[MaxC]

Also falls du es jemals veröffentlichen solltest: du weißt, wer davon unbedingt erfahren möchte

[Gast]

Alles klar Das wird wahrscheinlich aber noch dauern. Ich benutze es zwar schon in verschiedenen Projekten, aber Teile sind noch nicht final implementiert, es existiert im Prinzip keine Doku, etc.

Außerdem klingen mir jetzt schon die Ohren in Vorfreude auf die vielen:"Äh, das ist ja sch...e gelöst" und "Öh - Wieso hast Du das denn so und nicht so gemacht?!" und "Boah - Was ist denn das für ein Sch...-Skript!!!" usw.

[mquadrat]

Das liegt natürlich im Auge des Betrachters, aber mir persönlich gefällt diese Unterteilung einfach besser. Ein - wenn auch etwas sehr konstruiertes - Beispiel wäre: [schnipp]

Dann hab ich verstanden was du meinst. Prinzipiell liegen MVC und HMVC ja auch (logischerweise) nicht weit auseinander. Und wie man nun den Einsprungspunkt in die Bearbeitung definiert, ist ja Sache des Routings.

Ich hätte es nur spannend gefunden, wenn sich die Hierarchie in der URL niederschlagen würde. In meinem Framework ergibt die sich nur implizit. Insofern würde mich einfach eine Implementierung interessieren, die das explizit macht. Man lernt ja schließlich nie aus. Aber da gibt's hier ja (denke ich) genug Lesematerial

[dr.e.]

Ich hätte es nur spannend gefunden, wenn sich die Hierarchie in der URL niederschlagen würde.

Spannend? Das ist grober Unfug! Dieses Thema hatten wir mal in einem sehr länglichen Thread hier schon besprochen. In Verbindung mit HMVC macht die Abbildung von Controllern und Actions in der URL überhaupt keinen Sinn. Ich bin ebenso der Meinung, dass die sehr verbreitete Meinung, Controller und Actions müssen in die URL und man brauche ein Routing, das dieses dann auf Klassen und Methoden in der Anwendung von MVC mappen ebenso für nicht sinnig.

In meinem Framework ergibt die sich nur implizit.

Sofern du geschafft hast, das implizit in einer HMVC-Struktur abzubilden, hast du meiner Ansicht nach den Haupt-Preis gewonnen. Denn: du bist jetzt befähigt, ein beliebiges URL-Layout zu präsentieren, ohne 1000 Routen eintragen zu müssen.

[nikosch]

Ich bin ebenso der Meinung, dass die sehr verbreitete Meinung, Controller und Actions müssen in die URL und man brauche ein Routing, das dieses dann auf Klassen und Methoden in der Anwendung von MVC mappen ebenso für nicht sinnig.

Amen.

[dr.e.]

Amen.

Höre ich da Ironie?

[nikosch]

Nein, ganz im Gegenteil. Irgendwie scheinen mir die meisten Diskussionen immer (H)MVC und Command Control bzw. URL-basiertes Autoloading in einen Topf zu werfen bzw. zu verwechseln.

[Gast]

Ich hätte es nur spannend gefunden, wenn sich die Hierarchie in der URL niederschlagen würde.

Tut es doch..

domain.tld/User.Profile.Guestbook.Entry.Create/user/xxx

Mit User.Profile.Guestbook.Entry.Create wird der entsprechende Knoten aufgerufen. Irgendwie muss man ja per URL übergeben, wo man hin will. Oder habe ich etwas falsch verstanden? Vielleicht wurde mein Prinzip auch etwas falsch aufgefasst. Es geht letzten Endes nicht darum, Möglichst viele "Actions" gleichzeitig bedienen zu können, sondern der Fokus liegt darauf,
1. die Anwendung beliebig tief zu unterteilen
2. Die einzelnen Knoten generisch ansprechen zu können
Sachen wie z. B. eine "autonome" Newsbox könnten insofern geregelt werden, als das dort einfach die aktuelle URL um einen Parameter für das Paging der Newsbox erweitert wird.

[dr.e.]

Nein, ganz im Gegenteil. Irgendwie scheinen mir die meisten Diskussionen immer (H)MVC und Command Control bzw. URL-basiertes Autoloading in einen Topf zu werfen bzw. zu verwechseln.

Das scheint nicht nur so...

[nikosch]

Oder habe ich etwas falsch verstanden?

In Verbindung mit HMVC macht die Abbildung von Controllern und Actions in der URL überhaupt keinen Sinn

Irgendwie muss man ja per URL übergeben, wo man hin will.

In HMVC musst Du ohnehin irgendwo die Struktur hinterlegen. Dann kannst Du dort auch gleich einen Anknüpfpunkt schaffen und eigene Controller hinterlegen.

[Koala]

domain.tld/User.Profile.Guestbook.Entry.Create/user/xxx

sehen die tatsächlich so aus ?

Das hat aber mit "sprechenden" URLs / SEO nichts mehr zu tun.

Würd mir kein Auftraggeber abkaufen.

Man sollte möglichst frei sein bei der Gestaltuing der URL.

Und wenn der Auftraggeber will daß beim editieren des GB-Eintrag Nr. 14 als URL "domain.tld/huehnerfarm.html" stehn soll
dann ist das eben so.

So wie es bei mod rewrite ja auch (nahezu) beliebig machbar ist.

Irgendwie muss man ja per URL übergeben, wo man hin will.

Ja, das weiß/ermittelt der (Front-)Contoller anhand der Request-Parameter.

Vielleicht noch interessant was das ZF plant:
http://framework.zend.com/wiki/displ...rk+2.0+Roadmap
http://framework.zend.com/wiki/displ...ler_Router+2.0

[dr.e.]

Vielleicht noch interessant was das ZF plant:

Das hatte ich mir vor einer Zeit schon mal angesehen und es begeistert mich nicht wirklich. Es ist und bleibt quasi-statisches MVC-Routing und nutzt nicht den Ansatz der Entkopplung von URL und interner Applikations-Logik. Erst wenn du das schaffst kannst du

"sprechenden" URLs

korrekt verwirklichen. Es muss egal sein, ob da in der URL /new-products oder /new/products steht und ich möchte nicht irgendwelche Regexps nutzen müssen um das gegen einen Controller zu mappen.

Ja, das weiß/ermittelt der (Front-)Contoller anhand der Request-Parameter.

Meiner Ansicht nach sollte das nicht mal der Front-Controller tun, sondern ein eigener, vorher ausgeführter Filter, der das URL-Layout in eine intern verständliche Form überführt. In meinem Beispiel würde er /new-products in

$_REQUEST['page'] = 'new-products'; 

übersetzen und mit einer FC-Action kannst du dann entscheiden, welcher Seiten-Inhalt dargestellt und welche Meta-Angaben der Seite zur Verfügung gestellt werden müssen.