[Zope-dev] zope.catalog in ZTK

[Albertas Agejevas]

On Tue, Sep 29, 2009 at 01:09:08PM +0200, Martijn Faassen wrote:
> > About a year ago zope.app.catalog as been moved to zope.catalog.  I
> > think during this move there was a unique opportunity to leave these
> > event handlers behind in zope.app.catalog, so that the "no .app"
> > version is free of these forced choices.
>
> Doing this would have needed a migration strategy more complicated than
> "Oh, I'm just going to lose the ZMI when I switch" and people's
> applications somehow would have to gain registrations manually. I guess
> a damn good changelog would've helped somewhat..

Correct me if I'm wrong, but zope.app.catalog still remains with the
ZMI bits and re-imports of the zope.catalog functionality.  So apps
depending on zope.app.catalog are not affected at all.  I'm saying
that some of the event handlers (or their ZCML registrations) could
have stayed there as well.

> > But perhaps it's not too
> > late to do in now?  After all, no stable version of Zope 3 / ZTK
> > codebase has been released after this move?  People relying on
> > automatic indexing would have to register a couple of event handlers
> > in their configurations (or include zope.app.catalog), but the rest of
> > us would be able to choose the policy of how and when the objects are
> > registered with IntIds and indexed in the catalog.
>
> Would you propose the same treatment for zope.intid as well?

I don't know, the subscribers in zope.intid don't bother me too much.

> Would this involve removing the configure.zcml in these packages, or
> what is your proposal exactly?

In essence, I would like to see zope/catalog/subscribers.zcml removed
from the default zope/catalog/configure.zcml.

> Again, it needs damn good documentation if we were to go ahead with
> this, including details on how to register event handlers to accomplish
> the previous behavior. Both the changelog and the documentation that
> appears on pypi would need to be updated with instructions about what is
> going on. This change would also definitely be worth a feature release.
>
> +1 if documentation is good.

:D

Albertas