[Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/21/2011 02:13 PM, Jim Fulton wrote:
> On Mon, Mar 21, 2011 at 12:59 PM, Chris McDonough <chrism at 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.


FWIW, I just added 'queryAdapterFactory' and 'queryMultiAdapterFactory'
APIs to zope.component on a branch:

  http://svn.zope.org/zope.component/branches/tseaver-queryAdapterFactory/

These APIs make the "almost never overridden" / dependency injection
case as compact for adapters as for utilities.



Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2HqCYACgkQ+gerLs4ltQ7PFQCgnyoPFi8u8joVkA6wwDEL1ff0
IAcAn1l0s48CLGzVDRsF8tW32If7HCRm
=WoQO
-----END PGP SIGNATURE-----