[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.
GAH!
> 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
http://www.slinkp.com
More information about the Zope-CMF
mailing list