John Morton wrote:
> >  Why couldn't CatalogAware do this? If nobody has a good reason, I might
> >  push forth a patch to CatalogAware to implement this.
> A simple case for the present flexibility is that you don't need to reindex
> for every property change, just the ones that are actually indexed.

Agreed, CatalogAware should ideally check this to make sure reindexing
is necessary.

> A more complicated case would be an operation that changes several instances
> at once. It's expensive to reindex for every instance you change, so it would
> be useful to pass a flag to the ZClass's change method to tell it not to do a
> reindex, and reindex the lot once the operation over all the instances is
> completed.

I have actually done this for a Product I am developing. It allows you
to accumulate
property changes and reindex only once. Supposedly, the Catalog is more
efficient in this regard anyway as of 2.3.

> I guess that you could build this kind of functionality into CatalogAware,
> but I'm generally in favour of having flexible and optional rather than
> automatic reindexing, and just adding documentation to discuss some of the
> different cases.
> You could hack Property Sheet Interface to add a call to reindex if the
> ZClass is catalog aware.

I would not want to make PropertyManager directly aware of CatalogAware
if I could get away with it. Perhaps the way to deal with this is to
have PropertyManager call a hookable method afterChangeProperties or
some such, passing a list of properties changed. Then your ZClass could
simply call reindex_object if it feels it is necessary. That would give
full disclosure and behavior control back to your specific
implementation. But it would simultaneously cover property changes made
in the management screens and everywhere else.

I am moving this discussion over to zope-dev to see if anyone else there
has any ideas.

| Casey Duncan
| Kaivo, Inc.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to