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.g...@gmail.com
<mailto:woody.g...@gmail.com>> 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
<dragoo...@gmail.com <mailto:dragoo...@gmail.com>> 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"
<damianopetrung...@gmail.com
<mailto:damianopetrung...@gmail.com>> 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
<benjamin.m...@gmail.com <mailto:benjamin.m...@gmail.com>>
wrote:
Hey Hari,
On 18 Nov 2016, at 06:27, Hari K T
<kthar...@gmail.com <mailto:kthar...@gmail.com>> 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/94ac60a2-02ce-8332-5778-59f0011c8c20%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
