On 3/22/10 5:40 PM, Bernhard Schussek wrote:
Ad Approach 4:
Prefixing or suffixing services still leaves one problem unattended:
What if DI variables (like $maxPerPage) collide with request
parameters? Naming it $maxPerPageService obviously makes no sense.
Also, having a different magic in the constructor ($mailer) and the
actions ($mailerService) could be confusing for many developers.
My personal feeling is that the magic in the action methods may lead
to problems in big projects with lots of DI configuration. There it
can easily happen that services or DI variables collide with request
parameters. Unfortunately these collisions may not be obvious.
That's why routing variable always have precedence over DIC
services/parameters. That way, no change in the DIC can break a controller.
So, the only collision that can happen is when you implement a new
controller. And then, the developer will easily spot that he cannot use
a specific name in a route because it conflicts with an existing DIC
parameter. It can then rename it right away.
So, the process will be the something like this:
1. The developer creates a new route: /something/:maxPerPage
2. The developer creates the related controller:
function someAction($maxPerPage)
{
// do something
}
3. He wants to use the global parameter maxPerPage, so he adds it to
the signature:
function someAction($maxPerPage, $maxPerPage)
{
}
He realizes that it's not possible, so he renames the routing variable:
/something/:max
function someAction($max, $maxPerPage)
{
}
4. Problem solved
But most of the time, this won't happen. I think it will never happen in
fact. The routing parameter names should be quite short (like max)
because they are only used in a given context, whereas global parameters
tends to have more verbose names (as they can be used in any context).
So, the conflicts should be pretty rare.
Of course, for service names, this is a different story, but adding a
suffix like Service solves the conflict problem nicely.
Fabien
So, if we take this approach (which is compatible to most other
approaches) Symfony should warn the user when such collisions occur.
Bernhard
--
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.
