On 27.04.2011, at 21:40, Fabien Potencier wrote: > On 4/27/11 9:26 PM, Jordi Boggiano wrote: >> On Wed, Apr 27, 2011 at 8:11 PM, Lukas Kahwe Smith<[email protected]> >> wrote: >>>>> For FOSRestBundle I want to write a custom route matcher so that I can do >>>>> more complex Accept header negotiations on a per route basis. >>>>> Now I looked at how things are setup in the DIC and it seems there is a >>>>> "router" service which is an alias to "router.real". >>>>> However "router.real" seems to be used in most places rather than >>>>> "router", which seems counter intuitive to me, as I would expect I would >>>>> need to override the "router" service. >>>> >>>> Accept header negociations probably does not belongs to the Router >>>> Matcher. Can you explain what kind of stuff you want to do? Can't you >>>> create a listener before the request listener to do your stuff instead? >>> >>> >>> I have a listener that does this atm. However there is a severe limitation >>> in that the route cannot really have a say in its preferences. The solution >>> I have just allows you to set a global preference to resolves ties: >>> Imagine a request with Accept headers that set html at 1 and json at 1. I >>> can then configure the listener to prefer json. >>> >>> Imagine a request with Accept headers that set html at 1 and json at 0.5. >>> The route prefers json. Now I could expand the current solution to allow >>> boosting json for the entire application, but in most cases there will be a >>> mix of formats supported unless one has an entire application dedicated to >>> a single format. >>> >>> So really what is needed is a real negotiation on a per route level. >>> Aka the client defines its preferences via the Accept header and the route >>> defines its preferences via some configuration and then some algorithm >>> determines the best compromise. This cannot happen before or after >>> especially since I think there could be use cases where its determined that >>> there is no acceptable compromise and therefore other routes should be >>> considered. >> >> Thinking about it some more, maybe the routes should not check that at >> all, you could use annotations on the action and then a >> core.controller (is there such a thing?) event listener to check based >> on the request headers + what is defined on the action for supported >> formats then decide whether the request is acceptable or not, and if >> yes, set the preferred request format. > > Sounds much better to me.
But this means that the route is already matched. Which means you cannot automatically fallback to a route that better matches. 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
