[Fwd: [Framework-Team] Re: PLIP 145/168 - Locking and iterate]
optilude at gmx.net
Tue Nov 21 11:50:51 UTC 2006
On 11/21/06, Raphael Ritz <r.ritz at biologie.hu-berlin.de> wrote:
> [resending because my response originally went to Martin only
> - sorry Martin, I'll try to pay closer attention to the
> reply-to header in the future]
> -------- Original-Nachricht --------
> Betreff: [Framework-Team] Re: PLIP 145/168 - Locking and iterate
> Referenzen: <ejoa22$mfc$2 at sea.gmane.org>
> Martin Aspeli schrieb:
> > Speaking of which, is anyone picking up the Locking vs. iterate
> > situation? As I recall, they need a little bit of syncing before they
> > can happily co-exist, though Alec seemed to think the changes wouldn't
> > be that hard.
> Well, I still feel responsible for the locking part
> - in the end its me who wrote Plip 145 ;-)
> but I wonder whether this is still relevant at all.
> Depending on how we integrate iterate - if we do so -
> it could be that all we need is iterate's approach to
> locking. If, on the other hand, we make staging optional
> there would be a usecase for a locking mechnism as
> Jeff and I have been exploring at the Archipelago sprint.
I'm not hugely familiar with iterate, but I thought there was enough
difference between the two to warrant both. Specifically, iterate to
do check-out/check-in staging of documents, and PLIP145 to do
auto-locking when people edit documents (e.g. if staging is not in
use, or even on the staged copy), with lock stealing and the rest.
> As others have pointed out already, we would then need
> to support different locking policies or lock levels.
> E.g., content that's "checked out via iterate" would
> be treated according to iterate's policy (which mainly
> means no (easy) lock stealing) while items editied
> "in the traditional (TTW/TTP) way" would set WebDAV
> locks that could potentially be easily removed by others
> with editing rights.
> The other issue not settled so far is how to deal with the
> new "in-place edit" possiblities. Should we trigger locking
> there as well and if so, should this be for all field/widget
> types or just for TextFields or RichWidgets? Or should this
> be TTW configurable???
I'd say (a) in-place editing shouldn't be available if the document is
locked (obviously) and (b) it should trigger a stealable lock and
release when the field is saved. That presumes obtaining and releasing
locks isn't very expensive (I don't think it would be). Azax should be
capable of firing simple events to initiate the locking process.
If we can't get locks on in-place edits, I'd say is not as important
as having locks on the edit tab (since such edits would tend to be
much quicker), but respecting existing locks is important. I'd suggest
it should be on all widgets, too - I don't see any reason to treat
some widgets differently from others.
I'd also say we let such locks (which are stealable) work on the whole
object, rather than attempt some kind of field-level locking, since I
doubt there's a use case for simultaneous editing of different fields
on the same object.
> Regarding the currently somewhat close ties of Jeff and
> my locking approach to Archetypes which has correctly been
> pointed out as a weakness here, can anyone suggest a better
> alternative for where to put the firing of the "someone just
> started working on me" event (meaning more appropriate than
> 'base_edit' or the AT widgets)?
I'd suggest we have a generic event + a generic event handler,
alongside other generic code (plone.app.locking?), and then let
base_edit + azax (when initiating an in-place edit) fire those events.
What's not clear to me is how this locking and iterate's locking
interact and overlap. I think Alec had some ideas here, from what I
More information about the Framework-Team