The PSR-15 DelegateInterface uses this signature: https://github.com/http-interop/http-middleware/blob/master/src/DelegateInterface.php <https://github.com/http-interop/http-middleware/blob/master/src/DelegateInterface.php> Maybe it could be used also for this purpose, instead of something used exclusively inside a middleware.
> El 26 ene 2017, a las 20:08, Rasmus Schultz <[email protected]> escribió: > > We have support both for path-matching (via attributes provided by the > router) and multiple action-methods in our controller base-class - this > design doesn't prevent either of those things. > > I reckon you're taking the term "controller" as meaning something other or > more specific than the definition I use: anything that takes a request and > produces a response is a controller. > > How the request is interpreted, or what further steps or external > dependencies are involved in creating the response, is not defined, nor > relevant. > > If the term "controller" is confusing, try the term "dispatchable" or > "request dispatcher". > > Early on in the PSR-15 process, the same interface signatures was proposed as > the interface for dispatching a middleware-stack - having an interface that > is this generic for something that is that specific, is silly. > > This interface can be usefully applied to an endless number of > request/response scenarios - anything from a single controller, > middleware-stack or micro-framework, all the way up to complex frameworks > like Drupal or WordPress. > > I find it quite unopinionated - you can put behind that interface any kind of > controller-like concept you can imagine, there is absolutely nothing about > this interface that implies anything more than "takes a request, produces a > response", which will fit just about any top-layer of any PSR-7 based > architecture you can dream up, even clients for that matter. > > It seems a lot of you assign a lot more meaning and intent to this than I was > trying to convey - being able to build stand-alone controllers (or > base-classes) which could be supported by routers, is just one use-case. > There is absolutely nothing mandating that strategy over any other strategy. > > I obviously shouldn't have used the term "controller" - but to me, because > the term is so overloaded, it really doesn't mean anything specific. For > example, the term "controller" is common in client-side > view/model-abstractions, and "front controller" is common when describing a > catch-all "index.php", which is pretty far from something live a Drupal > controller. The term to me is about as open-ended as anything. > > I'd be fine with any other term, though personally I think "dispatcher" might > be even more overloaded - everything gets dispatched, HTTP requests, API > requests, methods, functions, closures.... > > What matters is that almost anything that uses PSR-7 under the hood could > potentially implement this interface on the server, which paves the way for > very high-level architecture, e.g. higher than middleware, where the > middleware runner itself could be described in the abstract at this level. > Currently those top layers have nothing formally in common and don't compose > well, besides, of course, as middleware, but then you've already made the > decision to use middleware, and that *does* imply architecture. > > > On Jan 26, 2017 19:03, "Matthew Weier O'Phinney" <[email protected] > <mailto:[email protected]>> wrote: > On Tue, Jan 24, 2017 at 1:14 PM, Rasmus Schultz <[email protected] > <mailto:[email protected]>> wrote: > >> While I can certainly see the value in the architecture this would imply, > >> it's by no means the only architecture > > > > I disagree that this implies architecture. > > > > "takes a request and returns a response" is in my opinion the least > > opinionated, most open-ended definition you can have of a controller - in my > > opinion, it does not imply architecture, at all. You're completely free to > > use traits, composition, base-classes, external services, registries, > > dependency-injection, middleware - anything you can dream up, the only > > requirement is that you ultimately take a PSR-7 request and produce a > > response, which, ultimately, if you're using PSR-7, you're going to, one way > > or the other. > > It does imply architecture, however: one controller, one action. > > Most MVC systems I've surveyed or participated in maintaining provide > a way to map multiple actions to a single controller, which > necessarily means multiple entry points: > > ```php > class SomeController > { > public function listAction($request) > { > } > > public function fetchAction($request) > { > } > > public function createAction($request) > { > } > > public function deleteAction($request) > { > } > } > ``` > > Sometimes this means standardization of method names (as detailed > above), sometimes there is a 1:1 relationship between an action and > the method name, sometimes there's a single entry method that then > dispatches to the appropriate method based on the action matched, etc. > > Additionally, I've seen systems that will pull path matches and pass > them as discrete arguments to the controller/action, often with the > request as a catch-all at the end of the list: > > ```php > // Route: /article/:id > public function update($id, $request) > { > } > ``` > > I personally have been pushing folks to follow the "1 route, 1 > controller" paradigm, which is what your proposal suggests, but that's > a _suggestion_; _requiring_ it via a standard, however, means any > implementing library _requires_ that approach, which I suggest would > limit adoption. > > -- > Matthew Weier O'Phinney > [email protected] <mailto:[email protected]> > https://mwop.net/ <https://mwop.net/> > > -- > You received this message because you are subscribed to a topic in the Google > Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/HD5meon7TX0/unsubscribe > <https://groups.google.com/d/topic/php-fig/HD5meon7TX0/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:php-fig%[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CAJp_myWsLaaPKMaT%3DwG1OvDjsw9KH7ZiEpWgvFKo2%2BfiVo55UA%40mail.gmail.com > > <https://groups.google.com/d/msgid/php-fig/CAJp_myWsLaaPKMaT%3DwG1OvDjsw9KH7ZiEpWgvFKo2%2BfiVo55UA%40mail.gmail.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CADqTB_i1adq_apAOnBc0PJguXmDz1dbQbZ1M3EE45k4HJCOnBQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/php-fig/CADqTB_i1adq_apAOnBc0PJguXmDz1dbQbZ1M3EE45k4HJCOnBQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/D620C423-EDB5-4247-8616-87A1347915E9%40gmail.com. For more options, visit https://groups.google.com/d/optout.
