On 3/24/10 4:49 PM, Francois Zaninotto wrote:
Hi devs,
I find the suffix approach quite verbose. When a controller needs to
deal with three or four services, this is going to be painful.
Also, the controller code actually deals with a Request object, not a
RequestService object. Unless all symfony core classes are inside a
Service namespace, it doesn't make much sense to rename all object
variables to '$somethingService' from a developer's point of view.
Especially if the names of the service variables in the constructor
don't match. An internal technical problem (like name conflict) should
not lead to reducing code usability.
I don't know how the routing works in symfony 2, especially for
additional GET parameters, but isn't there a risk of 'service parameter
injection' if I ever write such a controller:
function showAction($slug, $mailerService, $maxPerPageParameter)
{
}
And that controller is matched by this URL:
foo/show?maxPerPageParameter=2500 ? According to the controller code,
this may reveal as risky as SQL injection attacks.
This cannot happen. Only parameters from the routing can be injected in
the method arguments.
All in all, maybe the fact that request parameters need to appear in the
controller method signature is a constraint that we don't want to deal
with. If the signature only contained service or SC parameter variables,
it would be much simpler and more intuitive.
That's another approach. Don't allow routing parameters to be injected
and only allow services and parameters. This way, we can have something
like:
function showAction(Request $request, $maxPerPage)
{
}
What others think?
Fabien
After all, we wrote a lot of $request->getParameter('foo') in symfony 1
and nobody died...
My 2c.
François
2010/3/24 Lukas Kahwe Smith <m...@pooteeweet.org <mailto:m...@pooteeweet.org>>
On 24.03.2010, at 13:33, Jordi Boggiano wrote:
> On 24.03.2010 13:09, Lukas Kahwe Smith wrote:
>> This ties into my attempt to diverse this thread onto the
question of why controllers are not managed by the service container
[1]. In this case the issue of service vs. parameter would be solved
and would reduce introspection magic to method level injection.
> On the other hand, maybe the routing could be reworked if we
defined all
> controllers in the SC, you could have for example:
>
> blog:
> pattern: /blog/
> defaults: { _service: blogController, _action: list }
>
> And then in SC:
>
> blogController:
> class: BlogBundle\ViewController
> parameters:
> db: @db
>
> etc.
>
> Now the benefit is that you can change the entire blog stuff at once
> from the SC and also don't have class names mixed into the
routing config.
Reusing parameters between services and controllers also becomes
easier. Again I also see this as quite empowering when dealing with
controllers provided by bundles, this might even make it inevitable
that we move controllers to the SC.
In okapi2 we have made it a best practice to have a separate SC
config file for all the commands (action classes or controllers in
symfony lingo)
> The big downside is that you force everyone to understand how the SC
> works at least at a basic level, I'm not sure if we can afford
that or not.
Like I said in the my previous post, we do not necessarily need to
drop the simplified configs, they can however just generate SC
configurations:
http://groups.google.com/group/symfony-devs/msg/f35af2429c195eee
regards,
Lukas Kahwe Smith
m...@pooteeweet.org <mailto:m...@pooteeweet.org>
--
If you want to report a vulnerability issue on symfony, please send
it to security at symfony-project.com <http://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 symfony-devs@googlegroups.com
<mailto:symfony-devs@googlegroups.com>
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
<mailto:symfony-devs%2bunsubscr...@googlegroups.com>
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
<http://unsubscribegooglegroups.com> or reply to this email with the
words "REMOVE ME" as the subject.
--
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 symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
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.
--
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 symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
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.
