On Mon, Mar 21, 2011 at 12:59 PM, Chris McDonough <chr...@plope.com> wrote:
> On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote:
...
>> It's easy and clear, but has the drawback of encouraging that
>> registration is done on import time, while scanning separates the
>> registration from the definition. I'm not sure how important that is.
>
> It's important to me, at least. Registration-on-import effectively
> requires that there only be a single component registry for all
> applications in a process. This is often fine for a given deployment,
> but as a framework strategy it seems very limiting.
I'll note that this thread started with me saying:
"ZTK projects use ZCML too much. Ideally, ZCML should only have to
be used when we want to override something."
and:
"I think we ought to come up with a much cleaner way of defining
default configuration."
The intent of this thread, for me, was to come up with a cleaner way
to define *default* configurations. The scope is narrower than all
configuration. I'm thinking of use cases like the ones Tres mentioned
where you now use default arguments to queryUtility and queryAdapter.
Having a static way to express default configuration in no way
prevents you from utilizing local registries, any more than hard
coding defaults in calls to component-lookup APIs does.
So where do "static" definitions make sense? I think static
definitons make sense in library code when you own one of the
interfaces, as in Tres' examples. I'm not positive, but I strongly
suspect that this situation covers lots of registrations we now do in
ZCML.
I would argue that static definitions make sense in application code
when you're pretty sure how you want to hook things up, although in
this case, whether to express these application defaults in Python or
ZCML (or whatever) is a matter of taste. (There are also some potential
conflict issues that might make doing this sort of configuration
statically unattractive.)
One could argue about how much can be expressed as a static default
configuration. Maybe elimination of all ZCML is too ambitious a goal,
but I think we can avoid a lot of ZCML we have now.
I'll probably make some concrete proposal at a later time. I trying
to avoid saying more in this thread now, but I thought it was
important try to be clearer aout what this thread was supposed to be
about.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
