On 04.12.2010, at 17:44, Marijn wrote:
>
>
> On Dec 4, 5:11 pm, Lukas Kahwe Smith <[email protected]> wrote:
>> On 04.12.2010, at 17:02, Marijn wrote:
>>
>>> Now I understand the arguments that lead us to create a
>>> ContainerAwareInterface for controllers but wouldn't we be better of
>>> if we would just inject services into our controllers.
>>
>> Well some people prefer injecting the container instance others prefer
>> explicit injection. I am in the later camp, but arguments can be found for
>> either approach.
>>
>>> At that point it is the developers responsibility to ensure that those
>>> services are used for those actions. If they might not be used, then
>>> there is probably happening to much in that controller anyway.
>>> Besides that there are the other widely known arguments regarding
>>> testing.
>>> One could even argue to use one class per action (which I still think
>>> is a relatively small cost but works great given you can still have a
>>> common base class to share methods and as a side-effect create really
>>> lean controller objects).
>>
>> Emailing is one of those services that will often be optional if one groups
>> multiple actions inside a single controller. Now one could argue that to
>> send an email one would simply have to forward to an "email controller",
>> which might be feasible for some indeed and remove the need for this rarely
>> used and expensive swift mailer service.
>
> Exactly, so why would you want to create a "new_message" service?
well its one approach .. but everybody has their style.
actually there could be another approach.
instead of putting a wrapper around the service, one could also put a wrapper
around the container.
let me explain, the issue of heavy optional services really only effects
developers that do not want to inject the container to have more control over
the dependencies of their controllers (aka being explicit about the
dependencies and there by being able to swap out dependency implementations on
a per controller basis). now what if one could easily inject a container proxy
for which one could define the names of the services to expose?
mail_container:
class: Bundle\OptionalContainerBundle\Container\Optional
arguments:
container: @service_container
servicemappings:
mailer: foomailer
shared: true
fooDefault:
class: Application\FooBundle\Controller\DefaultController
arguments:
request: @request
templating: @templating
optional: @mail_container
shared: true
class DefaultController
{
public function __constructor($request, $templating, $optional)
{
$this->request = $request;
$this->templating = $templating;
$this->optional = $optional;
}
public function barAction()
{
$mailer = $this->optional->get('mailer');
}
}
Now this is just brainstorming, since having to define a service for every kind
of mapping configuration seems kind of ridiculous.
regards,
Lukas Kahwe Smith
[email protected]
--
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
