[Zope-dev] Stripping down zope.component

[Tres Seaver]

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

Martijn Faassen wrote:

> Thanks for the clarifications concerning registries. Does the multiple 
> registry situation mean any changes to the implementation of the ZCML 
> directives at all or will they just work as soon the underlying registry 
> situation is adjusted?

All the directive handlers do is create actions and add them to the
parsing context:

  http://svn.repoze.org/repoze.zcml/trunk/repoze/zcml/__init__.py

There isn't any there there, in the sense you are looking for.

> Another point is that we need to make sure we have a path for libraries 
> that use zope.component[zcml] to upgrade.

Actually, we don't need an upgrade path.  We can just leave a
'meta.zcml' in zope.component which <includes> the new locations.  That
file will be *inert*, and doesn't therefore need testing, because none
of the directive implementations will be present.

Over time, people can shift to including the new meta.zcml at their
leisure.  We can leave the redirecting meta.zcml in zope.component
*forever*, if need be.

The subscribers registered in zope.component's configure.zcml are a
different story:  I have a YAGNI feeling in my gut about them, but
haven't dug into who actually subscribes to verify it.  At any rate, we
can leave that zcml file as is unless / until we decide to rip out the
zope.event dependency.

> They will now need to import zope.componentzcml at the least, but where 
> does that leave zope.persistentregistry? Who needs to depend on this? 
> zope.site or something like that?

zope.site doesn't need *persistent* registries.  The traversal bit of
the publisher just needs to notice that the traversed object implements
the "I'm a site" interface, and call 'setSite'.

The only code which *needs* persistent registries is the code which
*implements* a registry as an attribute of a persistent object
implementing that marker interface.

> Anyway, this upgrade path needs to be spelled out clearly in the 
> zope.component CHANGES.txt pointing people in the right direction. We 
> also need to spell it out in this document:
> 
> http://svn.zope.org/zope3docs/source/migration/34to35.rst

Maintaining that document is out of scope for me. ;)

> (I hope this and related documents will soon move to the 'zopeframework' 
> area)
> 
> It'd be nice if we could organize some volunteers to check and adjust 
> any dependencies on zope.component that would need to be adjusted. I 
> think that mainly means checking those places that actually rely on 
> zope.component[zcml], but I think the baseregistry refactoring means 
> checking some other places as well.

I think that the *real* clients of that extra are all the site.zcml
files which which do the following:

  <include package="zope.component" name="meta.zcml"/>

The tiny fraction of hardcore types who actually import the
zope.component.zcml module are certainly competent to adjust those imports.


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJsIk5+gerLs4ltQ4RArFaAJ4m+OBOzd1zMszKu/UnmIwSgmGtkgCfbtso
mRJBgLU7muEomTu04VjfnKw=
=J4da
-----END PGP SIGNATURE-----