> 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. On Fri, Dec 30, 2016 at 5:17 PM, Damiano Petrungaro < damianopetrung...@gmail.com> wrote: > 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 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/CAOOfSh7saK3zmOF2ne1NOApnGD7sTC9puaO6WUHKhFqArPg7Ww%40mail. > gmail.com > <https://groups.google.com/d/msgid/php-fig/CAOOfSh7saK3zmOF2ne1NOApnGD7sTC9puaO6WUHKhFqArPg7Ww%40mail.gmail.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/CADqTB_j1OTYhZyuyzCEy8GC%2B%2BpXW7m2RZ5jh%2BJCMKx2YLgN9UQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
