-----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 <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.
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 tsea...@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----- _______________________________________________ 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 )