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. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/ -- 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
