Re: Routing PSR

[Majid abdolhosseini]

I almost agree with what you said,
just static call in my mind is not best practice.
and also for matching we should, we should be able to give uri or request 
object to match function.

because I belive in some cases uri and http method are not only options we 
make our matching strategy based on them.
for example consider based on "accept-lang" header or ... you want to have 
different callables.


$router->add(method, 'uri', callable)

$router->get('uri', callable)
$router->post(...)


$router->match($request)

-- 
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/c9a913d3-8751-4c86-978f-aaffd8d9b3fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Damiano Petrungaro]

News about it?

On Saturday, December 31, 2016 at 6:26:45 PM UTC+1, Paul Dragoonis wrote:
>
>
>
> On Thu, Dec 8, 2016 at 11:17 PM, Damiano Petrungaro  > wrote:
>
>> Any news Paul?
>>
>
> Yeah, I have it here, but held back on releasing it just yet because I was 
> busy finishing PSR-16, and then Christmas happened :)
>
> Expect something in the next few days.
>
>
>  
>
>>
>>
>> On Saturday, November 19, 2016 at 7:16:31 PM UTC+1, Paul Dragoonis wrote:
>>>
>>> Hi Guys,
>>>
>>> I'm busy with my 3 children over the weekend so I'll be back on on wagon 
>>> on Monday.
>>>
>>> To clarify: what I've been working on is a HTTP Router specification, 
>>> that uses HTTP Messages standard, and the PSR Middleware standard.
>>>
>>> Speak on Monday.
>>>
>>> Many thanks,
>>> Paul
>>>
>>>
>>> On Sat, Nov 19, 2016 at 6:12 PM, Woody Gilk  wrote:
>>>
 Larry,

 I think this may be a difference, or lack of clarity, with language. My 
 interpretation is that this would be an HTTP Router proposal that would 
 use 
 HTTP Messages. My feeling is that this area is definitely open to 
 standardization, as there are many "routing" packages that effectively do 
 the same thing. 

 That said, I am not necessarily convinced that a callable is the 
 correct target. My only concern with allowing a "mixed" type is that it 
 cannot be strongly typed at the interface level.

 --
 Woody Gilk
 http://about.me/shadowhand

 On Sat, Nov 19, 2016 at 11:49 AM, Larry Garfield <
 la...@garfieldtech.com> 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  
> 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  
>> 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> 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 

Re: Routing PSR

[Larry Garfield]

On 12/30/2016 10:50 AM, Rasmus Schultz wrote:

> So, for you, any PSR is wrong?

I have been pretty heavily invested in the development of PSR-5 and 
PSR-15, and I rely on PSR-7 and others in my work every day.


So no.

If you're trying to dismiss my opinion without actually debating any 
of the points I made, that's not the way to go about it.


PSR standards, in my view, are about making things interoperable - not 
about reducing every domain entity to a lowest common denominator.


To give you a few practical examples, the cache PSRs do not specify 
how a cache is implemented or configured, only how it's consumed. The 
middleware PSR does not specify how middleware is implemented or how 
the components get created, only how they're dispatched. The logger 
PSR does not concern itself with how loggers are implemented, routed, 
configured, created, etc. - only how the logger works once it's 
created, configured and ready to use.


If a router PSR defines how routers are configured as well as how 
they're consumed, how is it you think any logger will be able to 
differ from another, in the way it's configured, the features it 
offers, or anything else that makes one logger conceptually or 
feature-wise different from any other logger?


If you standardize router configuration, you've standardized the 
actual feature-set. There will be no practical reason (beyond 
performance) to choose any one specific implementation over another - 
they will all do precisely the same thing.


The same is not true for things like logging frameworks, cache 
back-ends or middleware.


Reducing all practical use of all routers to a lowest common 
denominator is meaningless. If you do that, you only need one router, 
the fastest one - it doesn't matter if they have different 
routing-configuration features beyond the standardized feature-set, 
you won't be able to use them.


Being able to dispatch a router without knowing how it was configured 
or created is, yes, important - but the same is true for lots of other 
components which take a request and produce a response, and middleware 
already takes care of that.


So I genuinely don't understand what it is you're trying to accomplish.

In my honest opinion, it sounds like a solution looking for a problem.


I generally agree with Rasmus here.  Interface PSRs work best when the 
client library consuming it really only has one meaningful way to 
interact with the Thing (or the ways to do so can be reduced to one 
meaningful way with little to no loss of functionality), but there could 
be a variety of different implementations of the Thing for reasons other 
than "there are many like it, but this one is mine."  Logging is an 
extremely good fit for that.  Caching is a reasonable fit for that.  
HTTP messages are a decent fit for that. Routing?  I don't see that as 
fitting that model.


--Larry Garfield

--
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/e9776260-11b8-d1e0-8cff-e333bbeb0c36%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Daniel Plainview]

Some things make frameworks special and routing, in my opinion, one of it.
If you want to eliminate this uniqueness among frameworks, you make 
pointless to choose between them.

> give maximum flexibility
> not be bound to an implementation

These are mutually exclusive statements.

On Friday, November 18, 2016 at 12:12:16 AM UTC+3, Damiano Petrungaro wrote:
>
> Hi everyone.
>
> I'm doing a microframework (for educational purposes), with the goal of 
> use in the core only methods derived from the PSR interfaces, so as to give 
> maximum flexibility and not be bound to an implementation rather than 
> another.
>
> Now i'm thinking about a routing system, and i'm wondered, how a so 
> crucial component to web applications (used by all the frameworks) haven't 
> a standard.
>
> What do you think to propose it as a possible PSR?
>

-- 
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/b93caf66-0879-41cc-954e-9088ca31e3c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Damiano Petrungaro]

Any news Paul?

On Saturday, November 19, 2016 at 7:16:31 PM UTC+1, Paul Dragoonis wrote:
>
> Hi Guys,
>
> I'm busy with my 3 children over the weekend so I'll be back on on wagon 
> on Monday.
>
> To clarify: what I've been working on is a HTTP Router specification, that 
> uses HTTP Messages standard, and the PSR Middleware standard.
>
> Speak on Monday.
>
> Many thanks,
> Paul
>
>
> On Sat, Nov 19, 2016 at 6:12 PM, Woody Gilk  > wrote:
>
>> Larry,
>>
>> I think this may be a difference, or lack of clarity, with language. My 
>> interpretation is that this would be an HTTP Router proposal that would use 
>> HTTP Messages. My feeling is that this area is definitely open to 
>> standardization, as there are many "routing" packages that effectively do 
>> the same thing. 
>>
>> That said, I am not necessarily convinced that a callable is the correct 
>> target. My only concern with allowing a "mixed" type is that it cannot be 
>> strongly typed at the interface level.
>>
>> --
>> Woody Gilk
>> http://about.me/shadowhand
>>
>> On Sat, Nov 19, 2016 at 11:49 AM, 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 >> > 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  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"  > 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 > > wrote:
>>
>>> Hey Hari, 
>>>
>>> On 18 Nov 2016, at 06:27, Hari K T  
>>> 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.

Re: Routing PSR

[Damiano Petrungaro]

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  > 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 > > 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" >> > 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  wrote:

> Hey Hari, 
>
> On 18 Nov 2016, at 06:27, Hari K T  
> 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.

Re: Routing PSR

[Paul Dragoonis]

Hi Guys,

I'm busy with my 3 children over the weekend so I'll be back on on wagon on
Monday.

To clarify: what I've been working on is a HTTP Router specification, that
uses HTTP Messages standard, and the PSR Middleware standard.

Speak on Monday.

Many thanks,
Paul


On Sat, Nov 19, 2016 at 6:12 PM, Woody Gilk  wrote:

> Larry,
>
> I think this may be a difference, or lack of clarity, with language. My
> interpretation is that this would be an HTTP Router proposal that would use
> HTTP Messages. My feeling is that this area is definitely open to
> standardization, as there are many "routing" packages that effectively do
> the same thing.
>
> That said, I am not necessarily convinced that a callable is the correct
> target. My only concern with allowing a "mixed" type is that it cannot be
> strongly typed at the interface level.
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
> On Sat, Nov 19, 2016 at 11:49 AM, 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  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 
>>> 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> 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 
> wrote:
>
>> Hey Hari,
>>
>> On 18 Nov 2016, at 06:27, Hari K T  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 

Re: Routing PSR

[Woody Gilk]

Larry,

I think this may be a difference, or lack of clarity, with language. My
interpretation is that this would be an HTTP Router proposal that would use
HTTP Messages. My feeling is that this area is definitely open to
standardization, as there are many "routing" packages that effectively do
the same thing.

That said, I am not necessarily convinced that a callable is the correct
target. My only concern with allowing a "mixed" type is that it cannot be
strongly typed at the interface level.

--
Woody Gilk
http://about.me/shadowhand

On Sat, Nov 19, 2016 at 11:49 AM, 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  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 
>> 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> 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 
 wrote:

> Hey Hari,
>
> On 18 Nov 2016, at 06:27, Hari K T  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.
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 

Re: Routing PSR

[Woody Gilk]

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  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> 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 
>> wrote:
>>
>>> Hey Hari,
>>>
>>> On 18 Nov 2016, at 06:27, Hari K T  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.
>>>
>>> -- TYPO3 Core Team Leader
>>> Support the project: http://typo3.org/donate/
>>>
>>> --
>>> 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/to
>>> pic/php-fig/Fj0QoGB1xLU/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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/ms
>>> gid/php-fig/A8BB6ABD-75E9-4678-9180-F6EE02FA2A4E%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/ms
>> gid/php-fig/CAOOfSh5-QJYg%3D77HVqDT5pHo5tuymc3vAsKrQm93SW%
>> 3DqKMMzYQ%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/CAKxcST9KiOSi1auXTNgxxU5mP1-_X4Rr4xEfwQC4UgZcrnpaBA%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/CAGOJM6KzoEZtcCems%3Dh9GVFCRNQtFVc%2BiVW3Kk70ziEWkijOYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Woody Gilk]

It seems like the people are ready for it.

On Fri, Nov 18, 2016, 15:54 Paul Dragoonis  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> 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 
> wrote:
>
> Hey Hari,
>
> On 18 Nov 2016, at 06:27, Hari K T  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.
>
> -- TYPO3 Core Team Leader
> Support the project: http://typo3.org/donate/
>
> --
> 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/Fj0QoGB1xLU/unsubscribe.
> To unsubscribe from this group and all its topics, 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/A8BB6ABD-75E9-4678-9180-F6EE02FA2A4E%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/CAOOfSh5-QJYg%3D77HVqDT5pHo5tuymc3vAsKrQm93SW%3DqKMMzYQ%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/CAKxcST9KiOSi1auXTNgxxU5mP1-_X4Rr4xEfwQC4UgZcrnpaBA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

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+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/CAGOJM6LjcOCuw6fJT-UBTnFJDZNwvwkc_ubfhyDbNicXX5b%3DRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Paul Dragoonis]

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" 
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 
> wrote:
>
>> Hey Hari,
>>
>> On 18 Nov 2016, at 06:27, Hari K T  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.
>>
>> -- TYPO3 Core Team Leader
>> Support the project: http://typo3.org/donate/
>>
>> --
>> 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/Fj0QoGB1xLU/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/A8BB6ABD-75E9-4678-9180-F6EE02FA2A4E%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/CAOOfSh5-QJYg%3D77HVqDT5pHo5tuymc3vAsKrQm93S
> W%3DqKMMzYQ%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/CAKxcST9KiOSi1auXTNgxxU5mP1-_X4Rr4xEfwQC4UgZcrnpaBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Benni Mack]

Hey Hari,

> On 18 Nov 2016, at 06:27, Hari K T  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.

-- TYPO3 Core Team Leader
Support the project: http://typo3.org/donate/

-- 
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/A8BB6ABD-75E9-4678-9180-F6EE02FA2A4E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Hari K T]

I believe , we should allow Router to do one thing, finding / matching the 
route, generating the route.

Dispatching based on the route should be done by dispatcher.

If you are curious what I am talking consider looking into the examples 
https://github.com/auraphp/Aura.Dispatcher#closures-and-invokable-objects .

I believe that is the best way you can remove complexity of dispatching on 
the router.

-- 
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/aaec1fff-1095-4780-8986-3fc0cbe6484b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Woody Gilk]

What would the use case for that be? I've never seen a system that worked
that way.

Here is how I would define the interfaces:
https://gist.github.com/shadowhand/543e4e507bf90feffd6bc63427c7e53b

See comment at the end for implied usage.

--
Woody Gilk
http://about.me/shadowhand

On Thu, Nov 17, 2016 at 5:24 PM, Damiano Petrungaro <
damianopetrung...@gmail.com> wrote:

> I didn't realize that you meant only the naming, my fault.
>
> Anyway i imagine the RouterMatcherInterface as an object that will
> contains one or more RouterInterface, and handle the matching of the uri
> with a Route and will invoke the callable.
>
> Example having different RouterInterfaces, the RouterMatcherInterface
> could prefer to use one of many.
>
> So the routing system will be able to handle different RouterInterfaces
> implementation.
>
> Maybe i am just over engeneering the moment of dispatching.
>
> On Friday, November 18, 2016 at 12:09:14 AM UTC+1, Woody Gilk wrote:
>>
>> I wasn't implying it should be static, just stating naming. I think I
>> agree with you about the first two interfaces. What is the purpose of
>> RouteMatcherInterface?
>>
>> On Thu, Nov 17, 2016, 17:03 Damiano Petrungaro 
>> wrote:
>>
>>> I would like to avoid static methods, they are harder to test.
>>> I prefer something (very basic example) like this
>>>
>>> https://gist.github.com/damianopetrungaro/d3da280e20bd5b22c0
>>> 9c64174114ac2a
>>>
>>> We should also discuss if is better to call the "add" method or "map".
>>> I don't know which one is the most diffused.
>>>
>>> I imagine like some interfaces like:
>>> RouteInterface as representation of the single route,
>>> RouterInterface as collector of Routes,
>>> RouteMatcherInterface as object that can contains more RouterInterface
>>> that will match and dispatch the action.
>>>
>>> On Thursday, November 17, 2016 at 11:34:46 PM UTC+1, Woody Gilk wrote:
>>>
 To me, the expressive implementation goes way beyond what a router
 does, which is:

 Map an http method and a URI expression to a callable:

 Router::add(method, urix, callable)
 Router::get(urix, callable)
 Router::post(...)
 // etc for http methods

 And then match a URI to a registered route:

 Router::match(uri) : Route

 Middleware is a totally separate thing and I think it's weird to put it
 here. Especially since middleware can do routing for you, no need for a
 separate step.


 On Thu, Nov 17, 2016, 16:08 Matthew Weier O'Phinney <
 mweiero...@gmail.com> wrote:

>>> On Thu, Nov 17, 2016 at 3:12 PM, Damiano Petrungaro
>
  wrote:
> > I'm doing a microframework (for educational purposes), with the goal
> of use
> > in the core only methods derived from the PSR interfaces, so as to
> give
> > maximum flexibility and not be bound to an implementation rather than
> > another.
> >
> > Now i'm thinking about a routing system, and i'm wondered, how a so
> crucial
> > component to web applications (used by all the frameworks) haven't a
> > standard.
> >
> > What do you think to propose it as a possible PSR?
>
> With Expressive, we've actually started down this direction already,
> and Michael has been urging me to submit our ideas around this as well
> as templating as potential recommendations.
>
> Maybe take a look at zend-expressive-router and its RouterInterface,
> Route class, and RouteResult as a place to start?
> (https://github.com/zendframework/zend-expressive-router)
>
> I'm certainly willing to discuss!
>
>
> --
> Matthew Weier O'Phinney
>
 mweiero...@gmail.com


> https://mwop.net/
>
> --
> 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/CAJp_myW7zjLEFRhaN
> g4Qtz9gLFf4JWpfXwZcK2wszLCuiKS3Rw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
 --

 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/ms
>>> gid/php-fig/2d837646-e3bd-4735-b8ce-ac269bbca9a1%40googlegroups.com
>>> 

Re: Routing PSR

[Damiano Petrungaro]

I didn't realize that you meant only the naming, my fault.

Anyway i imagine the RouterMatcherInterface as an object that will contains 
one or more RouterInterface, and handle the matching of the uri with a 
Route and will invoke the callable.

Example having different RouterInterfaces, the RouterMatcherInterface could 
prefer to use one of many.

So the routing system will be able to handle different RouterInterfaces 
implementation.

Maybe i am just over engeneering the moment of dispatching.

On Friday, November 18, 2016 at 12:09:14 AM UTC+1, Woody Gilk wrote:
>
> I wasn't implying it should be static, just stating naming. I think I 
> agree with you about the first two interfaces. What is the purpose of 
> RouteMatcherInterface?
>
> On Thu, Nov 17, 2016, 17:03 Damiano Petrungaro  > wrote:
>
>> I would like to avoid static methods, they are harder to test.
>> I prefer something (very basic example) like this
>>
>> https://gist.github.com/damianopetrungaro/d3da280e20bd5b22c09c64174114ac2a
>>
>> We should also discuss if is better to call the "add" method or "map".
>> I don't know which one is the most diffused.
>>
>> I imagine like some interfaces like:
>> RouteInterface as representation of the single route,
>> RouterInterface as collector of Routes,
>> RouteMatcherInterface as object that can contains more RouterInterface 
>> that will match and dispatch the action.
>>
>> On Thursday, November 17, 2016 at 11:34:46 PM UTC+1, Woody Gilk wrote:
>>
>>> To me, the expressive implementation goes way beyond what a router does, 
>>> which is:
>>>
>>> Map an http method and a URI expression to a callable:
>>>
>>> Router::add(method, urix, callable)
>>> Router::get(urix, callable)
>>> Router::post(...)
>>> // etc for http methods
>>>
>>> And then match a URI to a registered route:
>>>
>>> Router::match(uri) : Route
>>>
>>> Middleware is a totally separate thing and I think it's weird to put it 
>>> here. Especially since middleware can do routing for you, no need for a 
>>> separate step.
>>>
>>>
>>> On Thu, Nov 17, 2016, 16:08 Matthew Weier O'Phinney <
>>> mweiero...@gmail.com> wrote:
>>>
>> On Thu, Nov 17, 2016 at 3:12 PM, Damiano Petrungaro

>>>  wrote:
 > I'm doing a microframework (for educational purposes), with the goal 
 of use
 > in the core only methods derived from the PSR interfaces, so as to 
 give
 > maximum flexibility and not be bound to an implementation rather than
 > another.
 >
 > Now i'm thinking about a routing system, and i'm wondered, how a so 
 crucial
 > component to web applications (used by all the frameworks) haven't a
 > standard.
 >
 > What do you think to propose it as a possible PSR?

 With Expressive, we've actually started down this direction already,
 and Michael has been urging me to submit our ideas around this as well
 as templating as potential recommendations.

 Maybe take a look at zend-expressive-router and its RouterInterface,
 Route class, and RouteResult as a place to start?
 (https://github.com/zendframework/zend-expressive-router)

 I'm certainly willing to discuss!


 --
 Matthew Weier O'Phinney

>>> mweiero...@gmail.com
>>>
>>>
 https://mwop.net/

 --
 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/CAJp_myW7zjLEFRhaNg4Qtz9gLFf4JWpfXwZcK2wszLCuiKS3Rw%40mail.gmail.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>>>
>>> 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/2d837646-e3bd-4735-b8ce-ac269bbca9a1%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
>
> 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+unsubscr...@googlegroups.com.
To post to this group, send email to 

Re: Routing PSR

[Woody Gilk]

I wasn't implying it should be static, just stating naming. I think I agree
with you about the first two interfaces. What is the purpose of
RouteMatcherInterface?

On Thu, Nov 17, 2016, 17:03 Damiano Petrungaro 
wrote:

> I would like to avoid static methods, they are harder to test.
> I prefer something (very basic example) like this
>
> https://gist.github.com/damianopetrungaro/d3da280e20bd5b22c09c64174114ac2a
>
> We should also discuss if is better to call the "add" method or "map".
> I don't know which one is the most diffused.
>
> I imagine like some interfaces like:
> RouteInterface as representation of the single route,
> RouterInterface as collector of Routes,
> RouteMatcherInterface as object that can contains more RouterInterface
> that will match and dispatch the action.
>
> On Thursday, November 17, 2016 at 11:34:46 PM UTC+1, Woody Gilk wrote:
>
> To me, the expressive implementation goes way beyond what a router does,
> which is:
>
> Map an http method and a URI expression to a callable:
>
> Router::add(method, urix, callable)
> Router::get(urix, callable)
> Router::post(...)
> // etc for http methods
>
> And then match a URI to a registered route:
>
> Router::match(uri) : Route
>
> Middleware is a totally separate thing and I think it's weird to put it
> here. Especially since middleware can do routing for you, no need for a
> separate step.
>
>
> On Thu, Nov 17, 2016, 16:08 Matthew Weier O'Phinney 
> wrote:
>
> On Thu, Nov 17, 2016 at 3:12 PM, Damiano Petrungaro
>
>  wrote:
> > I'm doing a microframework (for educational purposes), with the goal of
> use
> > in the core only methods derived from the PSR interfaces, so as to give
> > maximum flexibility and not be bound to an implementation rather than
> > another.
> >
> > Now i'm thinking about a routing system, and i'm wondered, how a so
> crucial
> > component to web applications (used by all the frameworks) haven't a
> > standard.
> >
> > What do you think to propose it as a possible PSR?
>
> With Expressive, we've actually started down this direction already,
> and Michael has been urging me to submit our ideas around this as well
> as templating as potential recommendations.
>
> Maybe take a look at zend-expressive-router and its RouterInterface,
> Route class, and RouteResult as a place to start?
> (https://github.com/zendframework/zend-expressive-router)
>
> I'm certainly willing to discuss!
>
>
> --
> Matthew Weier O'Phinney
>
> mweiero...@gmail.com
>
>
> https://mwop.net/
>
> --
> 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/CAJp_myW7zjLEFRhaNg4Qtz9gLFf4JWpfXwZcK2wszLCuiKS3Rw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
>
> 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+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/2d837646-e3bd-4735-b8ce-ac269bbca9a1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

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+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/CAGOJM6Kv0mtSxLEGOhPb5qMS%2BcKKwu3QsFyQGJPkrhO0YpnkVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Matthew Weier O'Phinney]

On Thu, Nov 17, 2016 at 3:12 PM, Damiano Petrungaro
 wrote:
> I'm doing a microframework (for educational purposes), with the goal of use
> in the core only methods derived from the PSR interfaces, so as to give
> maximum flexibility and not be bound to an implementation rather than
> another.
>
> Now i'm thinking about a routing system, and i'm wondered, how a so crucial
> component to web applications (used by all the frameworks) haven't a
> standard.
>
> What do you think to propose it as a possible PSR?

With Expressive, we've actually started down this direction already,
and Michael has been urging me to submit our ideas around this as well
as templating as potential recommendations.

Maybe take a look at zend-expressive-router and its RouterInterface,
Route class, and RouteResult as a place to start?
(https://github.com/zendframework/zend-expressive-router)

I'm certainly willing to discuss!


-- 
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/

-- 
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/CAJp_myW7zjLEFRhaNg4Qtz9gLFf4JWpfXwZcK2wszLCuiKS3Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.