[Framework-Team] Re: plone.app.locking

Martin Aspeli 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:

http://svn.plone.org/svn/plone/plone.app.locking/trunk/

Now, I need to bake this into Archetypes. This turns out to be a bit 
tricky. Basically:

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 
implementation.

  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 
calling context/@@plone_lock_operations/notify_edit_begins.

  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 
lock stealing.

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 
hacks.

What do you think?

Martin





More information about the Framework-Team mailing list