The current interfaces are different than what you have listed here and the discussion has been resolved. I recommend looking at the current proposal if you have additional questions.
https://github.com/php-fig/fig-standards/tree/master/proposed/http-middleware -- Woody Gilk http://about.me/shadowhand On Sun, Oct 15, 2017 at 1:41 AM, kapitanluffy pirata <kapitanlu...@gmail.com > wrote: > Hi, I have the same idea as Oscar but I call the dispatcher as > MiddlewareStack. > > Can someone explain how this violates SRP? As far as I can understand it, > the stack/dispatcher is only responsible for handling/delegating the > request to the next middleware. > > That's why the interface only has "handle" as the method > > > interface MiddlewareStackInterface > { > public function handle(RequestInterface $request) : ResponseInterface; > } > > > > While the middleware is responsible of processing the request and > returning a response. > > > interface MiddlewareInterface > { > public function process(ServerRequestInterface $request, > MiddlewareStackInterface $stack): ResponseInterface > } > > > > By passing the stack/dispatcher in the middleware, you may choose to > create the response or > let the stack/dispatcher handle/delegate the request to the next > middleware > *(which I think is the same responsibility, or I am interpreting SRP > wrong?).* > > On Monday, August 15, 2016 at 9:15:25 PM UTC+8, Oscar Otero wrote: >> >> Hello. Maybe this is a bad idea, but just in case: >> Why not merge frameInterface with StackInterface in just one interface, >> let’s say ‘DispatcherInterface’? >> For example: >> >> interface DispatcherInterface >> { >> public function dispatch(RequestInterface $reques) : >> ResponseInterface; >> } >> >> interface ServerMiddlewareInterface >> { >> public function process(ServerRequestInterface $request, >> DispatcherInterface $next): ResponseInterface >> } >> >> So, each time the method “dispatch” is called, the next frame is executed >> and the response returned. So a typical middleware should be: >> >> class AddFooHeader implements ServerMiddlewareInterface >> { >> public function process(ServerRequestInterface $request, >> DispatcherInterface $next) >> { >> $response = $next->dispatch($request); >> return $response->withHeader(‘Foo’, ‘Bar’); >> } >> } >> >> And to execute this: >> >> $response = $dispatcher->dispatch($request); >> >> IMHO, It’s simpler and easier to understand. >> >> >> And in addition to that, we could add methods to return the psr-7 >> factories to use them inside the middleware: >> >> interface DispatcherInterface >> { >> public function dispatch(RequestInterface $reques) : >> ResponseInterface; >> public function getResponseFactory(); >> public function getStreamFactory(); >> //etc... >> } >> >> >> >> El 15 ago 2016, a las 14:35, Michael Cullum <m...@michaelcullum.com> >> escribió: >> >> Glenn & Woody, >> >> Please make sure you are aware of the self-throttling rules. >> >> -- >> Many thanks, >> Michael C >> FIG Secretary >> >> On 15 August 2016 at 13:31, Glenn Eggleton <gegg...@gmail.com> wrote: >> >>> Naming things are hard if and only if their function is hard to >>> define.... I still don't see any added value in turning the $next into a >>> formal interface. >>> >>> Moving on from that: >>> >>> NextMiddlewareInterface might be okay for a name... >>> >>> NextMiddlewareInterface -> process ( Request ) >>> >>> >>> On Sunday, August 14, 2016 at 2:20:22 PM UTC-4, Woody Gilk wrote: >>>> >>>> On Sun, Aug 14, 2016 at 12:32 PM, Matthieu Napoli <matt...@mnapoli.fr> >>>> wrote: >>>> > so I wonder why we aren't using __invoke in that interface too >>>> > >>>> > That's a very good idea, it might be a good middle ground: >>>> > >>>> > >>>> > interface Next >>>> > >>>> > { >>>> > >>>> > public function __invoke(ServerRequestInterface $request) : >>>> > ResponseInterface; >>>> > >>>> > } >>>> >>>> I'm comfortable with this approach. The type hint would still have to >>>> be included, though: >>>> >>>> public function process(ServerRequestInterface $request, NextInterface >>>> $next) >>>> { >>>> return $next($request); >>>> } >>>> >>>> I also don't love name NextInterface but... naming things is hard. >>>> -- >>>> Woody Gilk >>>> http://about.me/shadowhand >>>> >>>> >>>> >>>> > >>>> > -- >>>> > 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 php-fig+u...@googlegroups.com. >>>> > To post to this group, send email to php...@googlegroups.com. >>>> > To view this discussion on the web visit >>>> > https://groups.google.com/d/msgid/php-fig/etPan.57b0ab4a.72d >>>> 7b9d0.16394%40mnapoli.fr. >>>> > >>>> > For more options, visit 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 php-fig+u...@googlegroups.com. >>> To post to this group, send email to php...@googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/php-fig/c025e5d9-991b-43b5-af97-3bb7df023870%40googlegroups.com >>> <https://groups.google.com/d/msgid/php-fig/c025e5d9-991b-43b5-af97-3bb7df023870%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit 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 php-fig+u...@googlegroups.com. >> To post to this group, send email to php...@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/php-fig/CAAqcDMjHWYx9Udft0uUj6EC9zbOr5d8E2vQFEgxEe5FAomF >> 5ng%40mail.gmail.com >> <https://groups.google.com/d/msgid/php-fig/CAAqcDMjHWYx9Udft0uUj6EC9zbOr5d8E2vQFEgxEe5FAomF5ng%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit 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 php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/php-fig/18cb539f-b304-49c1-8a9f-58a41cf0fd25%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/18cb539f-b304-49c1-8a9f-58a41cf0fd25%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6KPyu5kHAoK-X8Q_YzK7T6%2B5zuRDdaTAakpLcdY0bnj%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
