On 3/22/10 6:06 PM, Lukas Kahwe Smith wrote:
On 22.03.2010, at 13:29, Fabien Potencier wrote:
On 3/22/10 1:27 PM, Lukas Kahwe Smith wrote:
On 22.03.2010, at 13:18, Fabien Potencier wrote:
On 3/22/10 1:09 PM, Lukas Kahwe Smith wrote:
Approach 1:
I do not like approach 1 because of the circular references and the fact that
its not so easy to see the dependencies by just looking at the constructor (and
action method) signatures.
Which circular reference? I don't see any.
Isnt the controller also handled by the service container?
Nope. It is created by a listener.
Ok, that surprised me :)
In okapi2 we decided to have action classes be services as well. This way we
get all the power of the service container import capabilities (remember you
didnt want it in sfYaml .. now it seems you also added a trimmed down version
to the routing config parsing), but also you can easily replace things (like
say a bundle that you like depends on a bundle you dont like .. if they would
be using services it would be easy to just replace the one you dont like with
another implementation. Furthermore it makes handling of scalar/array
dependencies easier, since then you can also manage these as service container
parameters you can reuse in other action service definitions but also in other
dependencies without having to define them redundantly.
Now in case you do not want to expose all of that to the average user you could
bundle some tools that generate the service container definitions from some
more specialized syntax.
Controllers as services do not fit well with the Symfony DIC. I won't
say it's not possible, but it feels really weird to me.
The DIC primary purpose is to manage "global" objects, objects that need
to be referenced elsewhere (that's why it's named a container). It's
very different from a factory. Using the DIC for controllers means that
you will need to create a XML/YAML/PHP file to describe how to create
EACH controller. That seems impractical and redundant to me. Why?
Because the controller signatures already define the dependencies. So,
in this case, I'd rather prefer to add DIC description via annotations.
And even if we find a mechanism to automatically generate those
descriptions, using the DIC is then moot, as you will loose the
"flexibility".
You can also think about the controller loader class as yet another way
to create a service via the DIC if that helps. In the implementation,
everything will come from the DIC, so you will have all the flexibility
of the DIC.
I have tons of other arguments against this idea. let's discuss these
first if you want. As it's kind of difficult to discuss this by email,
we can also meet on IRC; it will be more interactive and I think we will
reach agreement faster ;)
Fabien
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
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.
