Just my two cents, guys. I don't think abstracting routers at a low level makes sense.
If I've selected a particular router, I've most likely selected it based on it's features in terms of configuration - standardizing on how routers are configured practically eliminates any reason to select any particular router, since you end up having to treat them all as precisely the same thing. Basically the only difference they can offer then, is performance. To give you a practical example, here's an entirely different router-concept: https://github.com/mindplay-dk/walkway This router doesn't even define routes up front - a sub-route doesn't even exist before you attempt to resolve it's parent route. Obviously this isn't going to fit with any sort of standard interface for configuration, and certainly not the one used in zend-expressive. It's an entirely different concept from most routers. With regards to route-resolution, I'm thinking, what is the purpose of abstracting route-resolution? Being able to dispatch the controller, presumably - whatever a "controller" may be. I think everything else can be regarded as implementation details. So it would be possible to abstract this at a very high level - a router is something that takes a request and may or may not produce a response. But that sounds exactly like middleware. Why or how is middleware not enough abstraction for router dispatch? What's the advantage to abstracting routers in more detail? When do I need it? Why? Why or how is "not being being to a specific implemention" of a router an advantage? Or flip the question and say, when/why/how is it a disadvantage to be bound to a particular router with a particular set of features? Why would I care which router I'm using if they all have to work the same? I would want the fastest one then. End of discussion right? In my opinion, you may be trying to standardize something that's going to erase the differences, or the reason to have different routers in the first place, to the point where really one implementation would be enough - there would be no reason to have or use more than one router, anywhere, ever. My problem with that is, if you picked a router like mine (above) you picked it because you like the concept, the idea. If you reduce routing to "one idea", there's no way it's going to have room for different concepts such as this one. Is there? On Thursday, November 17, 2016 at 10:12:16 PM UTC+1, 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/0f2fb424-4d52-4e12-864f-fb039174a2e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
