So, for you, any PSR is wrong? (If is so this is a very strong assertion). In my opinion the PSR is needed for some basic conpepts, and the router is one of this.
Il gio 29 dic 2016, 13:55 Rasmus Schultz <ras...@mindplay.dk> ha scritto: > 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 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/0f2fb424-4d52-4e12-864f-fb039174a2e1%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/0f2fb424-4d52-4e12-864f-fb039174a2e1%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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/CAOOfSh7saK3zmOF2ne1NOApnGD7sTC9puaO6WUHKhFqArPg7Ww%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
