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.
Fabien
Cheers
--
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
