[Framework-Team] plone.app.locking

[Raphael Ritz]

Martin Aspeli wrote:
> Hi guys,
> 

Hi Martin,

thanks for taking a lead on thsi!

> I took a look at the locking bundle last night (which doensn't seem to 
> run, but the code doesn't seem too complicated).
> 

it's true that it's broken ATM (more below)

> I'm in the process of making a plone.app.locking package which just 
> moves the generic locking code out of the AT branch and provides a 
> general adapter for the ILockable interface that supports locking using 
> WebDAV locks. My understanding of WebDAV and its locks is not so great, 
> but I believe this should work on all Zope 2/CMF objects that mix in the 
> relevant support, not just Archetypes.
> 
That's correct.

> To get the UI to work, I want to provide a couple of viewlets that (a) 
> trigger the auto-lock when base_edit is found (b) remove the auto-lock 
> when the base_edit form is unloaded (probably in JS) and

That's exactly what Jeff and I did and why it's broken ATM
(I think at least; doing AJAX on top of Zope 2 versus Zope 3's
templating engine seem to be incompatible). :-(
(Please, please prove me wrong ...)

> (c) provides 
> the lock status/lock stealing form.
> 

Basically this is all there. Seems to me that we are only talking
about some code re-arragnement.

> I imagine the (generalised) viewlet manager will be defined in AT, and 
> that plone.app.locking will provide specific viewlets for the locking 
> functionality. The actual functionality is found in a couple of views 
> (as they are in the locking bundle) so that non-AT edit forms can just 
> call the relevant things to get the lock support.
> 
correct

> I don't fully understand how/if this will interact with iterate's locks, 
> but I imagine they should be separate or that iterate could depend on 
> plone.app.locking (expanded however necessary).
> 
iterate also uses the WebDAV locks but the suggestion has been that
it should be harder if not impossible to steal a lock issued by iterate.
For that, we might need something like lock levels (or whatever)
in order to be able to distinguish locks.

> What do people think of this? The lock bundle was reviewed and 
> principally accepted, though there were some concerns of AT 
> invasiveness. By moving things around like this, I think we get around it.
> 
> I would *like* to just commit plone.app.locking and merge the remaining 
> support into AT and Plone without re-branching and re-bundling, to save 
> time. I can do so if people ahve reservations, though.
> 
+1 from me. (just do it ...)

Raphael

> Martin
> 
> 
> _______________________________________________
> Framework-Team mailing list
> Framework-Team at lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team