[Framework-Team] Re: plone.app.locking
optilude at gmx.net
Sun Dec 10 23:14:49 UTC 2006
Okay, status update:
I have factored the locking code out of the Archetypes PLIP145 branch by
Raphael and Jean-Francois, and into plone.app.locking.
Now, I've come to believe that we should make Archetypes (templates
only) depend on plone.app.locking. I'd like the go-ahead to merge this
into AT trunk now, unless people have better ideas - and then we'll have
locking functionality. :)
The code is here:
Now, I need to bake this into Archetypes. This turns out to be a bit
Archetypes is already aware of WebDAV locks. There is a variable
isLocked in base_edit.cpt that looks for a WebDav lock. If this is
found, a portalMessage is displayed and the edit fields are disabled.
For plone.app.locking, we need the following:
1. Eligible objects marked with ITTWLockable (a marker interface).
This could be done in Archetypes/configure.zcml or plone.app.locking's
configure.zcml, depending on which way the dependency should go.
2. The isLocked behaviour should really be
context/@@plone_lock_info/is_locked, though this is really just an
abstraction since plone.app.locking uses WebDAV locks in its default
3. The disabling-of-editing behaviour should not be in effect so long
as context/@@plone_lock_info/is_locked_for_current_user is True (that
is, don't make disable editing if the object is locked, but locked for
the current user)
4. When the edit form is loaded, we need to send an IEditBeginsEvent.
This is currently defined in plone.app.locking.events. The most obvious
place to do this is in the base_edit template; the event can be fired by
5. When the object is saved, the lock should be released.
plone.app.locking handles this by listening to
Products.Archetypes.interfaces.IObjectEditedEvent, so this requires no
more work in AT.
6. When the user cancels the edit operation, the lock should be
released. This requires a suitable event to be sent from go_back.cpy
(the handler for the Cancel button). We could add an event type in AT
for this, though. I'm not quite sure how we send an event from a .cpy,
but in the worst case we can delegate it to a view.
7. The same should happen on form unload, ideally. This can be done
easily enough with KSS, I imagine.
8. If the user is locked by another user, we need to present a form
that allows the current user to steal the lock. This can be done by
checking context/@@plone_lock_info/lock_is_stealable and then having the
form submit to context/@@plone_lock_operations/force_unlock.
The original suggestion was that we achieve this by making a viewlet
manager or two in Archetypes, and let plone.app.locking plugin into
these. However, this can't really address (2, 3, 6 or 8), because it
won't let us plug into the go_back.cpy action, it won't let us modify
the existing behaviour of isLocked in base_edit.cpy, and it won't let us
change the portalMessage that complains about the lock but doesn't offer
Thus, I've come to believe that we should just let Archetypes depend on
plone.app.locking, and not let plone.app.locking depend on anything
except Zope 2 WebDAV lock functionality. There is nothing Plone-specific
about plone.app.locking, it's all Zope 3 events, views and an adapter
talking to webdav.LockItem. Otherwise, I fear we'll be doing some silly
What do you think?
More information about the Framework-Team