"Phillip J. Eby" wrote:

At 08:00 PM 9/9/99 -0400, Michel Pelletier wrote:

...

Oh Oh! Don't forget transparent ZCatalog integration. I think there's plenty of interest, the question is resources. If your willing to marshal up some time to list requirements, I'll jump in on the code phase.

I can go ahead and tell you what will greatly ease Catalog-Calendar integration, as well as any number of other specialized cataloging projects...

Rework ZCatalog so that you can add arbitrary Index objects by containing them immediately inside the catalog rather than by having to use a management tab that only allows a hardcoded set of index types. Make ZIndex objects that, when added to a Catalog's folder-like area, automatically insert themselves into the catalog's index mapping structures. In this way, adding new types of indexing (such as a MultiValue index, or a DateRange index) is possible simply by creating a new ZIndex subclass. And indexes can then have their own management screens for options like requiring uniqueness, or allowing case-insensitivity and what-have-you. In this way, if we create a DateRange or TimeSpan index that puts each date into a BTree in order to better isolate objects, and does searches using the date algorithms I previously described, then that logic can be encapsulated where it belongs: in the search/retrieval mechanism, rather than in the event objects and calendar displays.

ZCatalog is a stadard object manager, and it's API is pretty flexible, so you can drop these kinds of objects into Catalog right now. The 'indexes' view in the mngmt interface is nothing special, I see no reason why its simple indexes and more complex Zope object indexes couldn't play well together.

Of course, this approach would also enable easy replacement of the standard text indexes and other index types with a wide variety of alternative indexes developed by interested parties.

Yep.

I'm not clear at this point whether it's possible for such an animal to be backward-compatible,

I don't think it would require any changes at all.

although it seems it might be, since one mainly needs to make ZIndex objects whose after-add/before-delete methods check to see if it's been put into something that smells like a ZCatalog, and then add/remove itself from the ZCatalog's indexing parts accordingly. The tricky bit would be keeping people from removing the indexes accidentally via the index management interface, while still allowing removal of ones that were added that way.

If you removed via the indexes view, i would effectivly remove the index from the Catalog, but *not* the Zope object inside Catalog 'folder'. The Zope object could be given a little button to re-add itself. I actually this this behavior makes sense.

Perhaps the upgraded ZCatalog class could convert instances of itself to the new format where possible, and drop the index management screen altogether. Or, perhaps it's just the index management interface that needs changing, to allow any class that smells like a ZIndex to be added.

There are a couple possilbilities. One of the goals of ZCatalog was easy index managment. What you see now is just the first design iteration. In any case, ZCatalog must allways be backwards compatable with older instances of itself, so some class attribute trickery and setstate magic must be used. -Michel