> The rules can be the following:
>
> * If the argument name matches a route variable, we use it ($id in the
> example)
>
> * If not, and if the argument name matches a service name, we use it ($user
> in the example)
>
> * If not, and if there is a default value, and if the argument is optional,
> we use the default value ($pi in the example)
>
> * If not, we throw an exception
I don't like this rules, because developers will often run into situations,
like:
1) Developer create route "/some/:user" with "defaults: { user: me }" & writes
controller for it;
2) Then he runs url "/some/evan" & gets "evan" in $user parameter of action;
3) Then he tries to run url "/some" & expect to get "me" in $user parameter
(because he gets "evan" in previous action), but gets sfUser instance instead!.
If we change order of rules & try to first match action parameter name with
service - we will drive developers in unpredictable situations, when some route
parameters will goes in action as expected & others will become services.
--
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
To unsubscribe from this group, send email to
symfony-devs+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
