[Zope-CMF] Re: Don't always set the modification date?

Paul Winkler pw_lists at slinkp.com
Sun Feb 13 16:04:27 EST 2005

On Sun, Feb 13, 2005 at 07:05:32PM +0100, yuppie wrote:
> 1.) Updating 'modification date' or not is policy and should be 
> customizable.

That's where I'm coming from.
> 2.) editMetadata() and edit() call reindexObject(). If you use 
> setModificationDate() *after* editMetadata() you have to make sure the 
> catalog is up to date.

Doh! Thanks for the heads-up.
> 3.) For historical reasons reindexObject() calls notifyModified(), not 
> the other way round. 

Are the reasons anything other than historical?
That feels wrong.
Would changing it break any known applications?

> So calling reindexObject() after 
> setModificationDate() sets a new timestamp.


> Calling 
> reindexObject(idxs=['modified']) preserves the timestamp and updates the 
> index, but doesn't update the brain / metadata in the catalog. 
> Occasionally I use this workaround:
>     obj.reindexObject(idxs=['suppress_notifyModified'])
> Of course that's expensive and just a hack.
> 4.) CMF 1.5 has the same issues with 'creators'.
> 5.) If CMFEvent will become reality cleaning up that mess should be easier.

Yeah. As time goes on, I find more and more cases where the lack of
events is really becoming a hindrance for me.
E.g. I often end up monkey-patching manage_afterAdd and friends
because there's no other obvious place to hook into 
objects being moved.


Paul Winkler

More information about the Zope-CMF mailing list