xm22

Nee - Ein HMVC-Knoten entspricht weitestgehend einer Deiner Actions. Stell Dir vor, die Action wäre ein Objekt mit run-Funktion, welche ein View zurück gibt. Ich sage also
$assembleComponent mappt intern auf eine ComponentFactory, die wahrscheinlich Deinem Verwalter entspricht. Eigentlich wäre es also

Mister Ad

dsentker

Ein klassischer DI / Service-Container also. So habe ich deine Aussagen auch verstanden, gehe jedoch nicht damit konform, ausgaberelevante Strukturen einem Service zu überlassen. Dafür gibt es die Action, die die Daten (sei es aus einem Model, Repository oder Service...) in eine View stopft.
Das wäre?



Also gibt es quasi keine Controller bei dir?

Und was macht die ComponentFactory dann mit dem String 'Klasse-des-HMVC-Knotens'? Sie initiiert das "Action-Objekt" mit diesen Namen und führt die Methode run aus?

__________________

Trainmaster

oder den View eines Service in einen anderen View stopft. Es gibt doch nichts schöneres, als die Verschachtelung von Views


Einen internen Request durch einen Router zu jagen, womöglich noch mit Mehrsprachigkeit. Einfach unnötig. Für interne Requests ist eine Auflösung nach einer einfachen Namenskonvention ausreichend. Oder aber die zentrale Filterung des Requests, wie es oftmals anzutreffen ist. Du möchtest doch nicht ernsthaft einen internen Request durch Filter jagen? Schließlich sind das Anweisungen, die nicht vom Client, sondern vom Programmierer selbst kommen.

Natürlich kannst du jetzt argumentieren, dass für SubRequests all solche Dinge deaktiviert sind. Ich jedenfalls bevorzuge eine eigene, saubere Implementierung für interne Requests als solch eine beschnitttene Pseudo-Request-Implementierung.

dsentker

Dem stimme ich zu - Verschachtelte Views sind schön - aber nur, solange der Controller diese initiiert. Der Service selbst sollte dies nicht tun. Ist aber Auslegungssache, das handhabt jeder sicher anders.

Was ist, wenn ich per URL-Parameter den Namen einer Route bekomme, die als Subrequest geladen werden soll? Ein interner Request kann auch durch äußere Parameter definiert werden.

Sind sie aus o.g. Gründen nicht.

Ich sehe meine Lösung ebenfalls als sauber an, da das Instanziieren eines Controllers durch eine einzige Struktur angestoßen wird. Und "Pseudo-Request" ist, denke ich, die falsche Wortwahl, da es ein Request wie jeder andere auch ist - nur eben intern ausgeführt wird.

Ich könnte das Argument gelten lassen, dass das Jagen eines Requests durch den Router und Filter womöglich mehr Zeit kostet. Das lasse ich gelten, jedoch
a) gibt es Caching und
b) wenn eine ControllerAction in eine andere gestopft werden soll, hat man auch noch anndere Möglichkeiten. Etwa gibt es eine ControllerFactory, die anhand von ControllerNamen, ActionNamen und Parameter ein ControllerAggregate erzeugt (der sich dann letztendlich ausführen lässt). Oder man instantiiert den Controller wie jedes andere Objekt auch (new \Application\Controller\FooController() )

__________________

xm22

Wie schon gesagt - Das war ein falsch benutzter Begriff.
Doch, aber eben keine Actions - Jeder HMVC-Knoten (Component) entspricht einer Action - Nur eben als eigenes Objekt.
Der STring enthält die Klasse des Components. Die ComponentFactory erzeugt die Instanz eines solchen und übernimmt das dazugehörige Dependency Injection. Zurück kommt das Component, auf welchen die run-Methode ausgeführt werden muss.

dr.e.

Auslegungssache ja, jedoch halte ich IoC auch hier für die beste Variante - sprich template-based HMVC. Damit ist über das composite pattern eine lose, gleichförmige Kopplung über Templates möglich und der Code wird sauber entkoppelt.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

dsentker

Das heisst, es wäre nicht falsch, seine View mit dem DI/Service-Container zu instanziieren? Das würde auf jeden Fall viele meiner Probleme lösen.

__________________

dsentker

Ich muss nochmal eine eigentlich beendete Diskussion aufgreifen:
Ich bin immer noch fest der Meinung, meine interne Request-Lösung für das Laden eines Controllers in einen anderen ist richtig. Um zu sehen, wie es andere Frameworks machen, bin ich (wieder mal) auf die Symfony2-Implementation gestoßen:
http://symfony.com/doc/2.0/book/cont...tml#forwarding

Es ist nahezu die gleiche Implementation, nur dass das "Forwarden" der HttpKernel übernimmt, bei mir der FrontController. Ich möchte nicht sagen, dass andere Frameworks gnadenlos richtig sind, aber ist Symfony2 denn mit dieser Technik so falsch?

__________________

Trainmaster

Symfony2 erlaubt es auch, Controller als Services zu definieren, siehe http://symfony.com/doc/current/cookb...r/service.html.

Und am Ende steht eines fest: Wir alle haben Recht.

dsentker

Oha. Das ist ja krank (nicht negativ gemeint). Aber das dachte ich auch, als ich sah dass selbst der HttpKernel ein Service ist. Ich weiss grad nicht, was ich davon halten soll.

Das sowieso

__________________