Ankündigung

Einklappen
Keine Ankündigung bisher.

Externen Komponenten den ServiceContainer zur Verfügung stellen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #31
    Zitat von xm22 Beitrag anzeigen
    Gar nicht Jede "Action" erhält einen Context und kann nicht "über den Tellerrand" hinausblicken. Die Action soll ja nicht wissen, wo und von wem und wie sie aufgerufen wurde.
    Akzeptiert Ist eben eine Auslegungssache.

    Das ist dann aber auch so schon kritisch. So bald da dann eine kleine Sache geändert wird, kommen die sich vielleicht auch so ins Gehege.
    Klar, das meinte ich mit den Kollisionen. Aber wie sonst meinst du dann deine Aussage:
    Die verschiedenen Eigabequellen zu separieren finde ich persönlich mittlerweile eher ungünstig. Wozu soll die Applikation wissen, ob ein Parameter per GET oder POST gekommen ist?

    Wobei bei Dir auch mit Routen noch das Problem bestehen kann, ist das eine Route irgendwann mal auf andere Actions zeigt
    Dann gibt es dafür aber einen guten Grund.

    Kommentar


    • #32
      Aber wie sonst meinst du dann deine Aussage:
      Wenn z. B. ein POST-Formular ein Feld mit dem Namen A enthält und dann noch per GET oder URL oder wie auch immer einen Parameter A übermittelt, könnte man das zwar mittels $_GET und $_POST unterscheiden, aber spätestens, wenn unerwartete Sachen auftreten, hat man viel Spaß beim Debuggen.. Von daher sollten identische Parameternamen auf jeden Fall vermieden werden. Und das Auslesen von Parametern über eine zentrale Stelle, wobei nicht zwischen der Herkunft der Parameter unterschieden wird, unterstützt dieses Paradigma.

      Dann gibt es dafür aber einen guten Grund.
      Meine Erfahrung ist die: Es gibt im Unternehmen eine Abteilung, die sich da SEO-Marketing nennt. Die denken sich den ganzen Tag tolle Sachen aus, die oftmals mit genau solchen Änderungen einhergehen. Da bleibe ich lieber auf der sicheren Seite..

      Kommentar


      • #33
        Wenn z. B. ein POST-Formular ein Feld mit dem Namen A enthält und dann noch per GET oder URL oder wie auch immer einen Parameter A übermittelt, könnte man das zwar mittels $_GET und $_POST unterscheiden, aber spätestens, wenn unerwartete Sachen auftreten, hat man viel Spaß beim Debuggen.. Von daher sollten identische Parameternamen auf jeden Fall vermieden werden. Und das Auslesen von Parametern über eine zentrale Stelle, wobei nicht zwischen der Herkunft der Parameter unterschieden wird, unterstützt dieses Paradigma.
        Schon klar - aber das steht trotzdem im Widerspruch zu deiner Aussage
        Die verschiedenen Eigabequellen zu separieren finde ich persönlich mittlerweile eher ungünstig. Wozu soll die Applikation wissen, ob ein Parameter per GET oder POST gekommen ist?

        Es gibt im Unternehmen eine Abteilung, die sich da SEO-Marketing nennt. Die denken sich den ganzen Tag tolle Sachen aus, die oftmals mit genau solchen Änderungen einhergehen
        Auch logisch - aber genau das ist ja der Vorteil von benannten Routen:

        Code:
        weatherRoute:
          scheme: weatherWidget/@zipCode
          bindings:
            _controller:
              default: Weather
        
            _action:
              default: weatherWidget
        
            zipCode:
              default: 00000
              match: \d+
        Kann ohne Probleme geändert werden auf

        Code:
        weatherRoute:
          scheme: superHyperWeather/extremeCheap/@zipCode/seoRocks
          bindings:
            _controller:
              default: Weather
        
            _action:
              default: weatherWidget
        
            zipCode:
              default: 00000
              match: \d+
        Der Name der Route ist der gleiche, auch der (interne) Parametername. Solange Controller und Action also nicht geändert werden, ist das URL-Schema so flexibel wie ein Gummiband

        Kommentar


        • #34
          Schon klar - aber das steht trotzdem im Widerspruch zu deiner Aussage
          Inwiefern?
          Der Name der Route ist der gleiche, auch der (interne) Parametername. Solange Controller und Action also nicht geändert werden, ist das URL-Schema so flexibel wie ein Gummiband
          Jetzt verstehe ich, was Du meinst Trotzdem behagt es mir nicht, dass interne Abhängigkeiten zu den Routen bestehen. Das bedeutet ja auch, dass für jede Action eine Route vorhanden sein _muss_. Das defaultmäßige /controller/action... passt da schon, ändert aber eben nichts an der Sache mit der Abhängigkeit. Ein Teil der Applikation hängt von einem anderen ab, obwohl es eben nicht sein müsste. Aber das ist meine Meinung

          Kommentar


          • #35
            Zitat von xm22 Beitrag anzeigen
            Inwiefern?
            Naja, erst sagst du, dass es dem Controller bzw. der Applikation piepegal ist, ob Parameter "id" aus POST oder GET oder whatever kommt. Dann aber, nach dem Äußern meiner Bedenken, sagst du ebenfalls, dass es Probleme geben kann, wenn der Paramter "id" einmal in POST und einmal aus der URL kommt.

            Das bedeutet ja auch, dass für jede Action eine Route vorhanden sein _muss_.
            Ich weiss nicht, ob ich dich richtig verstanden habe. Nicht jede Action braucht eine eigene Route - i.d.R. reicht ja die Standardroute (bzw. Fallbackroute) aus nach dem Schema controller/action/params. Wenn es jetzt SEO-Fritzen gibt, die für eine wichtige Seite eine ganz bestimmte URL wollen, so trägt man sie eben vor der Fallbackroute ein und gut ist.

            Kommentar


            • #36
              dass es Probleme geben kann, wenn der Paramter "id" einmal in POST und einmal aus der URL kommt.
              Ja - wenn er _gleichzeitig_ über verschiedene "Wege" übergeben wird - Dann gibt das durchaus Probleme. Aber das hat ja nichts mit der eigentlichen Aussage zu tun.

              i.d.R. reicht ja die Standardroute (bzw. Fallbackroute) aus nach dem Schema controller/action/params. Wenn es jetzt SEO-Fritzen gibt, die für eine wichtige Seite eine ganz bestimmte URL wollen, so trägt man sie eben vor der Fallbackroute ein und gut ist.
              Ich glaube, Du hast es schon verstanden. So meinte ich es auch. Dein Ansatz basiert eben darauf, das _alles_ ein Request ist. Daher verknüpfst Du das Routing und Bootstrapping usw. mit der Ausführung der eigentlichen Actions. Das stört mich.

              Kommentar


              • #37
                Zitat von xm22 Beitrag anzeigen
                Dein Ansatz basiert eben darauf, das _alles_ ein Request ist. Daher verknüpfst Du das Routing und Bootstrapping usw. mit der Ausführung der eigentlichen Actions. Das stört mich.
                Ich verstehe auch deinen Ansatz: Ein interner Aufruf für einen anderen Knoten erfolgt nicht über die Route selbst, sondern über eine Methode, die die Verwaltungsklasse des Triads erwartet.

                Bedeutet das, dass jeder Knoten seine eigene Verwaltungsklasse benötigt?

                Und:
                PHP-Code:
                $component $this->context->assembleComponent('Name-von-MVC-Knoten-Verwalter'$context);
                $component->run()->render(); 
                Wie spreche ich eine bestimmte Action an? Oder ergibt sich das aus dem $context?

                Kommentar


                • #38
                  Nicht 'Name-von-MVC-Knoten-Verwalter', sondern 'Name-von-MVC-Knoten'

                  Kommentar


                  • #39
                    Zitat von xm22 Beitrag anzeigen
                    Nicht 'Name-von-MVC-Knoten-Verwalter', sondern 'Name-von-MVC-Knoten'
                    Was genau bedeutet das?
                    Zitat von xm22
                    Der erste Parameter ist die Klasse des HMVC-Knotens.
                    Darunter verstehe ich einen Verwalter

                    Kommentar


                    • #40
                      Zitat von dsentker Beitrag anzeigen
                      Sehe ich das richtig, dass eure Kritik darauf abzielt, dass man theoretisch auch die zu inkludierende Action direkt ansprechen kann, ohne dafür einen Request zu setzen / zu simulieren?
                      Wenn du mich fragst: Ja.

                      Natürlich instanziiere ich nicht einfach einen Service, sondern ein Service-Container übernimmt diese Aufgabe und ist zudem noch für die Injizierung von kontextrelevanten Objekten zuständig.

                      Ein Request bleibt für mich in diesem ganzen Zusammenhang immer noch primär die Anfrage des Clienten. Damit ergeben sich meiner Meinung nach andere Anforderungen an die Verarbeitung des Requests, als es bei einem internen Request der Fall ist.

                      Kommentar


                      • #41
                        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
                        PHP-Code:
                        $this->context->assembleComponent('Klasse-des-HMVC-Knotens, ...); 
                        $assembleComponent mappt intern auf eine ComponentFactory, die wahrscheinlich Deinem Verwalter entspricht. Eigentlich wäre es also
                        PHP-Code:
                        $this->context->getComponentFactory()->assemble('Klasse-des-HMVC-Knotens, ...); 

                        Kommentar


                        • #42
                          Zitat von Trainmaster
                          Natürlich instanziiere ich nicht einfach einen Service, sondern ein Service-Container übernimmt diese Aufgabe und ist zudem noch für die Injizierung von kontextrelevanten Objekten zuständig.
                          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.
                          Zitat von Trainmaster
                          Ein Request bleibt für mich in diesem ganzen Zusammenhang immer noch primär die Anfrage des Clienten. Damit ergeben sich meiner Meinung nach andere Anforderungen an die Verarbeitung des Requests, als es bei einem internen Request der Fall ist.
                          Das wäre?



                          Zitat von xm22 Beitrag anzeigen
                          Nee - Ein HMVC-Knoten entspricht weitestgehend einer Deiner Actions.
                          Also gibt es quasi keine Controller bei dir?

                          Zitat von xm22 Beitrag anzeigen
                          Stell Dir vor, die Action wäre ein Objekt mit run-Funktion, welche ein View zurück gibt. Ich sage also
                          PHP-Code:
                          $this->context->assembleComponent('Klasse-des-HMVC-Knotens, ...); 
                          $assembleComponent mappt intern auf eine ComponentFactory, die wahrscheinlich Deinem Verwalter entspricht. Eigentlich wäre es also
                          PHP-Code:
                          $this->context->getComponentFactory()->assemble('Klasse-des-HMVC-Knotens, ...); 
                          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?

                          Kommentar


                          • #43
                            Zitat von dsentker Beitrag anzeigen
                            Dafür gibt es die Action, die die Daten (sei es aus einem Model, Repository oder Service...) in eine View stopft.
                            oder den View eines Service in einen anderen View stopft. Es gibt doch nichts schöneres, als die Verschachtelung von Views


                            Zitat von dsentker Beitrag anzeigen
                            Das wäre?
                            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.

                            Kommentar


                            • #44
                              Zitat von Trainmaster Beitrag anzeigen
                              oder den View eines Service in einen anderen View stopft. Es gibt doch nichts schöneres, als die Verschachtelung von Views
                              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.

                              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. [...] Du möchtest doch nicht ernsthaft einen internen Request durch Filter jagen?
                              Was ist, wenn ich per URL-Parameter den Namen einer Route bekomme, die als Subrequest geladen werden soll?
                              Schließlich sind das Anweisungen, die nicht vom Client, sondern vom Programmierer selbst kommen.
                              Ein interner Request kann auch durch äußere Parameter definiert werden.

                              Natürlich kannst du jetzt argumentieren, dass für SubRequests all solche Dinge deaktiviert sind.
                              Sind sie aus o.g. Gründen nicht.

                              Ich jedenfalls bevorzuge eine eigene, saubere Implementierung für interne Requests als solch eine beschnitttene Pseudo-Request-Implementierung.
                              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() )

                              Kommentar


                              • #45
                                ausgaberelevante Strukturen einem Service zu überlassen
                                Wie schon gesagt - Das war ein falsch benutzter Begriff.
                                Also gibt es quasi keine Controller bei dir?
                                Doch, aber eben keine Actions - Jeder HMVC-Knoten (Component) entspricht einer Action - Nur eben als eigenes Objekt.
                                Und was macht die ComponentFactory dann mit dem String 'Klasse-des-HMVC-Knotens'?
                                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.

                                Kommentar

                                Lädt...
                                X