Ok, thanks for your quick response, Woody. An yes, I admit the factory methods is a violation of SRP. But IMHO, the responsability of the stack is to execute the frames, and the DispatcherInterface example does just this (execute & move to the next), so I think there’s no violation here. The stack is inmutable so cannot be modified by any middleware, just executed. I don’t see more danger here than using a FrameInterface. This is just an idea to reduce this specification to the minimum required.
--- Oscar Otero https://oscarotero.com <https://oscarotero.com/> > El 15 ago 2016, a las 15:58, Woody Gilk <woody.g...@gmail.com> escribió: > > Oscar, doing that would be a violation of SRP and would allow > middleware to modify or inspect the stack. We should protect against > mistakes by design. > -- > Woody Gilk > http://about.me/shadowhand > > > On Mon, Aug 15, 2016 at 8:15 AM, Oscar Otero <oscarot...@gmail.com> 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 <geggl...@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.72d7b9d0.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+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/c025e5d9-991b-43b5-af97-3bb7df023870%40googlegroups.com. >>> >>> 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/CAAqcDMjHWYx9Udft0uUj6EC9zbOr5d8E2vQFEgxEe5FAomF5ng%40mail.gmail.com. >> 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/148B5B01-2B07-4996-97A7-5C30142BB15C%40gmail.com. >> 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/CAGOJM6JeTo3X%3Da1oQnVv-mLjJVOoNGQW_DRJ6%3DQxinX-_HXCaw%40mail.gmail.com. > 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/CA821DBC-1C5B-4CFF-A8A4-5AABF45E11CC%40gmail.com. For more options, visit https://groups.google.com/d/optout.
