Larry, i've limited experience, i am a developer just since 2 years, but have you ever used a routing based on something that skips the request object? Anyway, if your idea is to make a PSR router not only built for HTTP requests we're here to discuss about it. We could build a strategy pattern on the RouterInterface so what the different inputs, i can just imagine many ways for do a "loose coupling" router.
On Saturday, November 19, 2016 at 6:49:34 PM UTC+1, Larry Garfield wrote: > > Background: My primary experience with routing systems is the conversion > of the Drupal 7 menu/routing system to the Drupal 8 Symfony-based routing > system, and realizing the issues with the way most systems seem to do > routing today. :-) > > I am quite skeptical about a routing PSR at this point. Routing could be > based on a wide variety of inputs, not just the URL. Not even just the > request, although conceptually the non-request data (likely derived from > it, but also including DB calls) could be added to the attributes array for > later access. Even then, producing "a callable" may also be limiting, as > I've been questioning some of the decision we made in Drupal to allow > arbitrary callables as a route handler (controller). > > At this point I remain unconvinced that a Routing PSR would be viable > unless it was super-trivial. Even a Route definition object would be hard > to standardize; Drupal has a lot more there than Symfony does, and we're > based on the same underlying libraries. > > I've not looked at what Expressive is doing or what Paul is proposing, but > at this point it doesn't feel like an area with enough "natural > standardization" for a PSR to be viable. > > --Larry Garfield > > On 11/19/2016 11:51 AM, Cees-Jan Kiewiet wrote: > > Same here, would be very interested to see what Paul has in mind for a > routing PSR > > On Sat, Nov 19, 2016 at 5:18 AM, Woody Gilk <woody...@gmail.com > <javascript:>> wrote: > >> And if you have anything ready to share, I'd be interested to see it. >> >> -- >> Woody Gilk >> http://about.me/shadowhand >> >> On Fri, Nov 18, 2016 at 3:54 PM, Paul Dragoonis <drag...@gmail.com >> <javascript:>> wrote: >> >>> Hello everyone, >>> >>> I have been waiting to announce this until after I finish with PSR16, >>> but there's no time like the present. >>> >>> I have been working on the routing PSR for some time now, given my >>> passion and experience at integrating 5 different routers into PPI >>> Framework Engine. >>> >>> I have spoke with a few others about this over the past while i.e: MWOP >>> and others. >>> >>> I would be happy to push forward this PSR, by way of Editor, by >>> partnering up with someone (MWOP?), since we both have the experience at >>> building routing interop engines. >>> >>> On the basis that someone is willing to sponsor me. >>> >>> What do we say, is it time to release the cracken ? >>> >>> Many thanks, >>> Paul >>> >>> On 18 Nov 2016 1:01 p.m., "Damiano Petrungaro" <damianop...@gmail.com >>> <javascript:>> wrote: >>> >>>> What do you think about an interface that will be used by >>>> RouterInterface for dispatch an event using a specific method? >>>> In this way the dispatching implementation will be bounded inside a >>>> single RouterInterface (so we could imagine different RouterInterfaces and >>>> everyone will have a RouterDispatcherInterface implemented). >>>> >>>> It's ok to put the dispatching is somewhere else on the implementation >>>> level, but i would like to put it inside to PSR. >>>> >>>> On Fri, Nov 18, 2016 at 7:06 AM Benni Mack <benjam...@gmail.com >>>> <javascript:>> wrote: >>>> >>>>> Hey Hari, >>>>> >>>>> On 18 Nov 2016, at 06:27, Hari K T <ktha...@gmail.com <javascript:>> >>>>> wrote: >>>>> >>>>> I believe , we should allow Router to do one thing, finding / matching >>>>> the route, generating the route. >>>>> >>>>> Well, I think it should exactly do one thing - namely finding/match >>>>> the route. The generation is IMHO separate, and belongs to a route >>>>> generator or even URI/URL generator. >>>>> >>>>> I agree, dispatching is somewhere else on the implementation level... >>>>> >>>>> Best, >>>>> Benni. >>>>> >>>> > -- 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/18ed5bdd-a662-424a-ab90-44bd19140ed9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
