I think it would be annoying if i had to have a DI extension way of
overriding ALL parameters in my extension. The actual instances %.class for
example I always put into parameters only. I think we have to enable
developers here to go deep into the internals of an extension instead of us
having to write tons of code just to move parameters into the DI extension.
What I do find annoying though is when a configuration option can be
defined both through parameters and the DI extension. I found several such
"duplicates" in the Doctrine extension and removed them as good I can.
Other parameters in the Doctrine extension are now "read-only" for other
extensions to consume, i.e. the extension ALWAYS overwrites them with a
default value from the extension, so there is no way for you to set the
value in "parameters" and have it set this way.
greetings,
Benjamin
On Sat, 22 Jan 2011 19:43:16 -0800, Kris Wallsmith
<[email protected]> wrote:
This is a bug, IMO. The app developer should be able to set a parameter
to
override an extension's default parameters. Likewise, a service defined
in
the app config should override one defined in an extension with the same
id.
Fabien, do you see it differently? Is an extension's config array a
public
API and the parameters used internally part of a private API? If so, the
extension's parameters should never be merged back into the container,
and
the parameter bag never passed to the temporary container here…
https://github.com/fabpot/symfony/blob/master/src/Symfony/Component/D...
I think the solution is to fix this compiler pass so it respects
parameter
and services set by the app dev.
Thanks Ryan!
k
On Jan 22, 2011, at 3:45 PM, ryan weaver<[email protected]> wrote:
Ok, so my understanding has come full circle. Yes, it sucks that certain
parameters in DI extension resources can't be overridden as normal
parameters (since they're consumed by the DI extension class itself).
But,
as Fabien said, you shouldn't be doing this in the first place, and if
you
are - you're on your own. Plus, I found that removing these "special"
parameters seemed inconsistent. Many of these parameters are consumed by
the
DI extension simply due to the nature of the way the related service is
created. So, splitting information between the DI resource parameters
and a
new "options" array on the DI extension seemed unnatural.
So, this was a learning experience on my part. As Fabien said, the
options
exposed by a DI extension should be configured and "never" the
parameters
located in any resource loaded by the DI extension. The point is, if you
need to override the parameters from a DI extension, you're "on your
own".
The options exposed by the DI extension should be enough (and
well-doc'ed).
Thanks for the help!
Ryan Weaver
Lead Programmer - iostudio - Nashville, TN
http://www.iostudio.com
http://www.thatsquality.com
Twitter: @weaverryan
On Sat, Jan 22, 2011 at 4:14 PM, ryan weaver<[email protected]>
wrote:
Yes, Jordi, you understand me perfectly. I'm seeing this in the MongoDB
bundle, but perhaps the "bad practice" isn't very rampant. I'll put
together
a pull request removing some of these parameters and state my case
there.
Fabien, I suppose the documentation should *just* document the
available
"options" of a DIC and leave the discovery that lower-level things
could
be
overridden (such as service class names) to the advanced developer.
That
gives me good "philosophical" direction as well.
Thanks!
Ryan Weaver
Lead Programmer - iostudio - Nashville, TN
http://www.iostudio.com
http://www.thatsquality.com
Twitter: @weaverryan
On Sat, Jan 22, 2011 at 3:23 PM, Jordi Boggiano
<[email protected]>wrote:
On 22.01.2011 21:50, Fabien Potencier wrote:
Parameters are more low-level and should not be used if there is a
DIC
extension.
Of course, when you define your own services and parameters, the
story
is different. In that case, you don't need to create an extension
(except if you want to distribute your code). So, parameters become
the
way you can tweak your services.
I think he's onto something. If the "config.xml" files define
parameters
that are actually just used by the Extension class and then discarded,
I
think this leads to false expectations that you can define the
parameter
in your config file and override some value.
It's just a best practice thing, but I think it makes sense that a
parameter that is only accessible via the Extension config block
should
not be defined as a parameter in the DIC config. I have no idea how
common this "bad practice" is at the moment though.
Cheers
--
Jordi Boggiano
@seldaek ::http://seld.be/
--
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]<symfony-devs%2Bunsubscribe@google
groups.com>>>> For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--
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]<symfony-devs%2Bunsubscribe@google
groups.com>
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
