Maybe we need to implement the routing system a bit closer to the HTTP spec, so that it does more content negotiation than just relying on the url/method?
That would not only solve the problem for versioning, but also the problem that different controllers might consume/produce different media types. regards, Johannes On Oct 9, 5:19 pm, Lukas Kahwe Smith <[email protected]> wrote: > On Oct 9, 2011, at 09:53 , Lukas Kahwe Smith wrote: > > > > > > > > > > > > > On Oct 9, 2011, at 00:52 , Fabian Spillner wrote: > > >> First, I want to understand why we need the solution with multiple > >> resources per route (1). > > >> Your approach: > > >> rest: > >> resources: [foo_v1.rest.controller, foo_v2.rest.controller] > >> type: rest > > >> … is in fact the same to: > > >> rest_v1: > >> resource: foo_v1.rest.controller > >> type: rest > > >> rest_v2: > >> resource: foo_v2.rest.controller > >> type: rest > > >> Please, can you explain me the reasons? > > > From my reading it is not, as the YamlFileLoader will parse the file and > > then iteratively call the Rest loaders one at a time. Therefore if I want > > to realize that there is a relationship, I would have to look into the > > collection before adding a new route to determine if for the same patterns > > there already is a route written (just with a different version). Otherwise > > I would just override the previous routes. > > > Now I am not sure yet, but it might even be ok if we continuously overwrite > > previous routes since all we really need to make sure is that for each > > action in all of the controllers there is a route that matches them. So > > lets assume we do as you suggest above. > > > Then I am back at the issue I mentioned in my original email: > > Once I match a given pattern, how do I easily find _all_ controllers that > > match the given pattern, given that based on format AND version preferences > > I might need to first look at controller A, then at controller B and then > > at controller A again. Given this need I do not see how the current > > "iterate and forget about previous routes" is the right approach. Note I do > > not know the routing layer all that well yet, so maybe I am overlooking > > something here. > > OK, I have done some more big refactorings after reading some more of the > HTTP spec and I now have a nice solution for a single controller. > The problem is now exactly as explained above, if I register another > controller for the same pattern, then the matcher will just return the first > one, but I need to know which other controller are also candidates. > > One hacky solution would be to make the RestRouteCollection instance a class > property and then simply continuously add to that Collection. This way I > could detect if for the given pattern (I guess in this case I could actually > rely on just using the name) there was a route previously and then add more > information. Of course after each time the load() method is called I will > need to return the Collection instance, meaning it would get more and more > inefficient as the Collection size would grow and grow and I will override > more and more previously defined routes. Also having to extend the current > route based on a previous route is also tricky. > > > Note: > > The current code only works with Annotations and these Annotations are not > > cached. I will later probably move this code back into the route loader > > some how. But I did not quickly see a way to add additional data into the > > routes that would be returned when calling the match() method. > > ok that is fixed now, by putting the format priorities into the route defaults > > regards, > Lukas Kahwe Smith > [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
