Locking support

[jones]

Hi there

I'm wondering if there is locking support for dexterity right now?
Couldn't find anything.
What's planned about locking? Will there be a locking behavior?

Cheers

Jonas

[Baumann Jonas]

Hi

Since we need locking support in our dexterity project and I couldn't find
anything in dexterity, I started implementing a plone.app.lockingbehavior,
using plone.locking.

In Archetypes the plone.locking event handlers are registered on four events:
- AT IEditBegunEvent
- AT IEditCancelledEvent
- AT IObjectEditedEvent
- AT IObjectInitializedEvent

Theese events are for Archetypes, but I couldn't find any similar events which
could be used on dexterity objects.

Now I'm not sure which approach would be the best. If I would implement it
only in plone.app.lockingbehavior, I'd probably have to write custom edit- /
add-forms, which fire the events I need. But I think it's very ugly to register
forms for a behavior.

The other possibility would be to add the events to plone.dexterity and to
fire them in the default add/edit forms - but I'm not sure if it belongs there.

Are there any possibility? Or is there already something planned for making
locking work on dexterity content types?

Cheers

Jonas

[JMehring]

Hi.

I added an IEditBegunEvent in an early branch (for drafts) of
plone.dexterity.browser.add/edit in the update() method (before
calling super so context could be modified if needed before any
widgets were set up). Since then I have removed the event and rely on
z3cform adapters. Maybe it would be a good idea to add this back in?

All the other events could be handed from z3cform itself. Example
follows:

# Notifies when an action button has been pressed (Save / Cancel)
action.py:
zope.event.notify(ActionErrorOccurred(action, error))
action.py:
zope.event.notify(ActionSuccessful(action))

# Add / Modify
form.py:
zope.event.notify(zope.lifecycleevent.ObjectCreatedEvent(obj))
form.py
zope.event.notify(zope.lifecycleevent.ObjectModifiedEvent(content,
*descriptions))

Jason

[Martin Aspeli]

On 2 December 2010 11:21, Baumann Jonas <tsch...@gmail.com> wrote:
> The other possibility would be to add the events to plone.dexterity and to
> fire them in the default add/edit forms - but I'm not sure if it belongs there.

I'd be happy to have events in p.dexterity - obviously not the AT
ones, but some Dexterity-specific events. As Jason pointed out, the
drafting code also needs this.

I think the events we'd want are:

class IBegunEvent(Interface):
"""Base event"""

class IEditBegunEvent(IBegunEvent):
"""Event for the edit form""""

class IAddBeginEvent(IBegunEvent):
"""Event for the add form"""

class ICancelledEvent(Interface):
"""Base event"""

class IEditCancelledEvent(ICancelledEvent):
"""Event for the edit form""""

class IAddCancelledEvent(IBegunEvent):
"""Event for the add form"""

You don't need IObjectEditedEvent - IObjectModifiedEvent is fine. The
former is only needed to work around portal_factory issues in AT.

Same is true for IObjectInitializedEvent, just use IObjectAddedEvent
or IObjectCreatedEvent.

Martin

[Baumann Jonas]

Ok then, I'll add theese events and fire them in the forms.

I'd also need to protect the edit view, so that Unauthorized is raised when the
object is locked, and probably change condition of the edit-action so that it checks
whether the object is locked...

Where do you think should the behavior belong?
- plone.app.lockingbehavior (very optional)
- plone.app.dexterity.behaviors (as standard behavior)
- or even register it directly on Item (-1 on that one..)

Cheers

Jonas

[Martin Aspeli]

On 2 December 2010 15:34, Baumann Jonas <tsch...@gmail.com> wrote:

> Ok then, I'll add theese events and fire them in the forms.

Cool.

> I'd also need to protect the edit view, so that Unauthorized is raised when the
> object is locked, and probably change condition of the edit-action so that it checks
> whether the object is locked...

This is not something we can do at the FTI or core plone.dexterity
level, since it'd only apply when the behaviour is enabled. What does
AT do?

> Where do you think should the behavior belong?
> - plone.app.lockingbehavior (very optional)

yes.

> - plone.app.dexterity.behaviors (as standard behavior)

no

> - or even register it directly on Item (-1 on that one..)

no

Martin

[Baumann Jonas]

Am 02.12.2010 um 16:42 schrieb Martin Aspeli:
>
>> I'd also need to protect the edit view, so that Unauthorized is raised when the
>> object is locked, and probably change condition of the edit-action so that it checks
>> whether the object is locked...
>
> This is not something we can do at the FTI or core plone.dexterity
> level, since it'd only apply when the behaviour is enabled. What does
> AT do?

In AT the whole form is not rendered when the object is locked.
This is is done in the templates:
./base_edit.cpt: isLocked isLocked | lock_info/is_locked_for_current_user | nothing;
./edit_macros.pt: tal:condition="not:isLocked"

If the object is locked, a viewlet will be displayed, which allows to unlock (depending
on configuration). This viewlet should also work on dexterity, I guess (saw it once when playing
around with locking).

So we have to do it on the form, somehow.

One possibility is to customize the plone.app.z3cform templates using a adapter, but
I'm not sure if that's a good idea and how it would be done properly.

Maybe we could also use another approach, such as redirecting back to the default view
of the object, when it's locked. On this view should then the viewlet be displayed, so we
don't have to show an additional status message.

Or we could use a variable in the template, something like "show_form", which can be set by
the behavior on some point.

I don't know z3cform and autoform etc. that well, so I'm don't know what's the best and
easiest approach to do that. But raising a Unauthorized - like I mentioned above - is not a
good idea. It should be more verbose..

Jonas

[Gerhard Weis]

Hi,

How adding these events into some non-dexterity specific package. So they could be re-used by AT at some time (if this ever happens), and non-dexterity components.

I am thinking of locking events as re-usable components. The actual event handlers would probably need to be implemented in a framework specific package.

The following are just loud thoughts:

I have not thought this through but as a quick idea the event definitions could go into something like plone.locking.events, but then these events should probably be more generic. (e.g. IObjectLocked, IObjectUnLocked or ILockReleased, etc.....)

Another way would be to create some new z3cform.locking package which provides locking support in a generic way for form handling.

how does this sound?

cheers,

Gerhard

> --
> You received this message because you are subscribed to the Google Groups "Dexterity development" group.
> To post to this group, send email to dexterity-...@googlegroups.com.
> To unsubscribe from this group, send email to dexterity-develo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dexterity-development?hl=en.
>

[Martin Aspeli]

On 2 December 2010 21:57, Gerhard Weis <gerhar...@gmail.com> wrote:
> I have not thought this through but as a quick idea the event definitions could go into something like plone.locking.events, but then these events should probably be more generic. (e.g. IObjectLocked, IObjectUnLocked or ILockReleased,  etc.....)

+1, it's a plone.* package anyway, so it's an ok dependency for
plone.dexterity, and locking is "core" content management
functionality.

However, *enabling* locking would still need to be a behaviour. It
*could* become a behaviour in plone.locking (sine plone.behaviour is
not Dexterity specific), but it's probably more of a candidate for
plone.app.dexterity.behaviours then, if it's this "core".

Martin

[Gerhard Weis]

+1

yes, that's what I meant with the implementation of the event handlers itself will most likely have to go into a framework specific package. However, it might be possible to do it in a form-framework specific way and not necessarily content-framework specific way. (I guess there is some investigation necessary.)

cheers,

Gerhard

> Martin

[Baumann Jonas]

Am 03.12.2010 um 00:44 schrieb Gerhard Weis:

On 03/12/2010, at 8:22 AM, Martin Aspeli wrote:

On 2 December 2010 21:57, Gerhard Weis <gerhar...@gmail.com> wrote:

I have not thought this through but as a quick idea the event definitions could go into something like plone.locking.events, but then these events should probably be more generic. (e.g. IObjectLocked, IObjectUnLocked or ILockReleased,  etc.....)

+1, it's a plone.* package anyway, so it's an ok dependency for

plone.dexterity, and locking is "core" content management

functionality.

However, *enabling* locking would still need to be a behaviour. It

*could* become a behaviour in plone.locking (sine plone.behaviour is

not Dexterity specific), but it's probably more of a candidate for

plone.app.dexterity.behaviours then, if it's this "core".

+1

yes, that's what I meant with the implementation of the event handlers itself will most likely have to go into a framework specific package. However, it might be possible to do it in a form-framework specific way and not necessarily content-framework specific way. (I guess there is some investigation necessary.)

Currently, in plone.locking there are two event handlers (lock the object and unlock the object), which are not registered to any events.

In AT the event handlers of plone.locking are registered to the AT events - so nothing is actually "implemented" there, just registered.

So for using plone.locking on any content you have to:

- provide ITTWLockable (from p.locking)

- register the two event handlers (usually on the four events mentioned before)

- ensure, that the edit-form is not accessible by another user, if the object is locked

So creating new IObjectLocked etc. events would be more a p.locking thing, rather than a dexterity / archetypes thing. Although it

would be a nice to have them, it's not necessary for integration, since they should be fired e.g. AFTER the object is locked, but the

couldn't be used for triggering to lock the object. Or am I getting something wrong?

However, in the place where the dexterity behavior would be, we would just provide TTWLockable by using a behavior, and on

the behavior interface we register the the event handlers of p.locking on some events.

So no other package like p.dexterity or p.locking would ever use the behavior, since we could only check ITTWLockable - so

I think the dependencies should be okay.

Anyway, there is still the question how to trigger / check the locking stuff on the form.

We could do it either do it directly like this:

>>> if ITTWLockable.providedBy(self.context):

...    lockable = ILockable(obj)

...    if not lockable.locked():

...        lockable.lock()

We could also do a safe import of p.locking to check whether its there - so nothing happens if it's not used..

Or we could do it by adding the events to p.dexterity (IEditBegunEvent etc.) - which are then registered in the place where

the behavior lives, using the already existing event handlers in p.locking.

Then, the only thing is missing is to lock / protect the edit form.

To have a z3cform-locking thing, which implements it generally using p.locking, would be great I think..

Cheers

Jonas 

[Martin Aspeli]

On 3 December 2010 08:13, Baumann Jonas <tsch...@gmail.com> wrote:
> Anyway, there is still the question how to trigger / check the locking stuff
> on the form.
> We could do it either do it directly like this:
>>>> if ITTWLockable.providedBy(self.context):
> ...    lockable = ILockable(obj)
> ...    if not lockable.locked():
> ...        lockable.lock()
> We could also do a safe import of p.locking to check whether its there - so
> nothing happens if it's not used..

-1 for doing that in Dexterity - we don't do that kind of pollution of
the Dexterity codebase.

> Or we could do it by adding the events to p.dexterity (IEditBegunEvent etc.)
> - which are then registered in the place where
> the behavior lives, using the already existing event handlers in p.locking.

+1 - this is what I had in mind originally; the only variation was
whether we *define* the events in plone.locking or not, to which I'm
+0 if it gives any benefits for integration with other packages.

> Then, the only thing is missing is to lock / protect the edit form.
> To have a z3cform-locking thing, which implements it generally using
> p.locking, would be great I think..

-1 - locking is about content editing, not forms. People have edit
forms for things that are not content and not lockable. I don't think
it belongs at the form level, except to trigger events that signal
when things are happening so that locking can take place.

Martin

[Baumann Jonas]

Am 03.12.2010 um 09:27 schrieb Martin Aspeli:

> On 3 December 2010 08:13, Baumann Jonas <tsch...@gmail.com> wrote:
>
>> Or we could do it by adding the events to p.dexterity (IEditBegunEvent etc.)
>> - which are then registered in the place where
>> the behavior lives, using the already existing event handlers in p.locking.
>
> +1 - this is what I had in mind originally; the only variation was

> whether we *define* the events in plone.locking or not..

Ok, I was just confused about the proposed names of the events in locking (IObjectLocked),
which seems to me to be after locking and not to be used for triggering the locking..

> .. to which I'm

> +0 if it gives any benefits for integration with other packages.

Creating new events in p.locking would change the way p.locking is meant to
be used, I think. But maybe this would be a better approach than how it's currently
used. But anway, we need to do something in the form - maybe by hooking in
with an adapter?

>
>> Then, the only thing is missing is to lock / protect the edit form.
>> To have a z3cform-locking thing, which implements it generally using
>> p.locking, would be great I think..
>
> -1 - locking is about content editing, not forms. People have edit
> forms for things that are not content and not lockable. I don't think
> it belongs at the form level, except to trigger events that signal
> when things are happening so that locking can take place.

Is there a better way how to hook into z3cform so that we can protect the form?
Maybe there is some sort of adapter or something, which we could register?

Jonas

[Gerhard Weis]

On 03/12/2010, at 6:42 PM, Baumann Jonas wrote:

>
> Am 03.12.2010 um 09:27 schrieb Martin Aspeli:
>
>> On 3 December 2010 08:13, Baumann Jonas <tsch...@gmail.com> wrote:
>>
>>> Or we could do it by adding the events to p.dexterity (IEditBegunEvent etc.)
>>> - which are then registered in the place where
>>> the behavior lives, using the already existing event handlers in p.locking.
>>
>> +1 - this is what I had in mind originally; the only variation was
>> whether we *define* the events in plone.locking or not..
>
> Ok, I was just confused about the proposed names of the events in locking (IObjectLocked),
> which seems to me to be after locking and not to be used for triggering the locking..

well, these were not meant as proposal. Just to have some names to talk about.

>
>> .. to which I'm
>> +0 if it gives any benefits for integration with other packages.
>
> Creating new events in p.locking would change the way p.locking is meant to
> be used, I think. But maybe this would be a better approach than how it's currently
> used. But anway, we need to do something in the form - maybe by hooking in
> with an adapter?
>
>>
>>> Then, the only thing is missing is to lock / protect the edit form.
>>> To have a z3cform-locking thing, which implements it generally using
>>> p.locking, would be great I think..
>>
>> -1 - locking is about content editing, not forms. People have edit
>> forms for things that are not content and not lockable. I don't think
>> it belongs at the form level, except to trigger events that signal
>> when things are happening so that locking can take place.
>
> Is there a better way how to hook into z3cform so that we can protect the form?
> Maybe there is some sort of adapter or something, which we could register?
>

That's a good point. Distinguishing between locking events and triggering these locking events.

For the first category it would be about the actual locking. There may be a use for events like BeforeLocking, Locked and the similar for unlocking.

For triggering these events I think the corresponding form framework might be a good place. I guess as the locking is rather plone specific it should go into a plone.z3cform specific package for z3cform-based forms. Similar for AT if it's re-using the same trigger events.

For z3c.form in might be feasible to create something like an ILockingAwareForm interface (or adapter), which can be used to render an edit form non-editable. It should be possible to hook into some AfterWidgetUpdateEvent or so. (not sure whether this is the right hook, but I am sure there is something suitable within z3c.form that can be used.)

cheers,

Gerhard

>
> Jonas

[Martin Aspeli]

On 3 December 2010 08:42, Baumann Jonas <tsch...@gmail.com> wrote:
>
> Am 03.12.2010 um 09:27 schrieb Martin Aspeli:
>
>> On 3 December 2010 08:13, Baumann Jonas <tsch...@gmail.com> wrote:
>>
>>> Or we could do it by adding the events to p.dexterity (IEditBegunEvent etc.)
>>> - which are then registered in the place where
>>> the behavior lives, using the already existing event handlers in p.locking.
>>
>> +1 - this is what I had in mind originally; the only variation was
>> whether we *define* the events in plone.locking or not..
>
> Ok, I was just confused about the proposed names of the events in locking (IObjectLocked),
> which seems to me to be after locking and not to be used for triggering the locking..

Unwind.... the IObjectLocked thing was a separate suggestion. We may
need that too, but indeed this is an after-the-fact thing.

>> .. to which I'm
>> +0 if it gives any benefits for integration with other packages.
>
> Creating new events in p.locking would change the way p.locking is meant to
> be used, I think. But maybe this would be a better approach than how it's currently
> used. But anway, we need to do something in the form - maybe by hooking in
> with an adapter?

I'm getting too confused by all the proposals here. Why don't you take
a look and come up with what you think is the most appropriate
solution, and then describe it in one place. I think the main
constraints are clear:

- plone.dexterity can't depend on any Archetypes or plone.app.* package
- plone.locking can't depend on Archetypes or plone.dexterity
- No z3c.form package should depend on plone.locking
- We want to fire events in the add and edit forms and hook into
them, rather than hardcode locking support
- Locking has to be an opt-in behaviour

Martin

[Baumann Jonas]

Ok, I'll implement it that way and look how far I get :)

Cheers

[Jonas Baumann]

2010/12/3 Martin Aspeli <opti...@gmail.com>:

>
> I'm getting too confused by all the proposals here. Why don't you take
> a look and come up with what you think is the most appropriate
> solution, and then describe it in one place. I think the main
> constraints are clear:
>
>  - plone.dexterity can't depend on any Archetypes or plone.app.* package
>  - plone.locking can't depend on Archetypes or plone.dexterity
>  - No z3c.form package should depend on plone.locking
>  - We want to fire events in the add and edit forms and hook into
> them, rather than hardcode locking support
>  - Locking has to be an opt-in behaviour
>

Hey

I created a branch of plone.dexterity (jbaumann-locking - I know the
name, it's more a
stuff-to-do-for-making-locking work).
What I changed:
- added EditBegunEvent, AddBegunEvent, EditCancelledEvent, AddCancelledEvent
- added tests for the Begun-Events
- I couldn't add tests for the cancelled events - I'm not too familiar
with mocktestcase not
with the z3cform internals - I couldn't figure out what adapters I'd
have to register for
making the cancel-actions work in the tests. I'd be happy if someone
could look at it
and give me hint.
- Alan Runyan mentioned in the plone-cvs-list that begun and cancelled
is akward and
suggested to use Start, Stop, Abort - didn't change that yet

Is that ok? Who does the merge once its finished? Should I do it?

Then I created a plone.app.lockingbehavior, which is quite simple:
- it provides a ILocking behavior
- it registers the eventhandlers from plone.locking on the events of
plone.dexterity for
the ILocking interface

That's working so far. Docu for the lockingbehavior is missing, but
I'll do that..

The only problem is how to protect the edit-form, so that a user
cannot edit if another
user is locking the object.

I did quite a simple, but very dirty thing for that:
I registered an additional event-handler on IEditBegun, which raises a
Redirect to
context.absolute_url() if it's locked:
https://svn.plone.org/svn/plone/plone.app.lockingbehavior/trunk/plone/app/lockingbehavior/handlers.py
It works well and looks nice (it's a little bit different because the
user is redirected to the
default-view, but I think it's well too).

Is there a better z3cform-solution without creating another form?

Cheers

Jonas

[Martin Aspeli]

Hi Jones,

> I created a branch of plone.dexterity (jbaumann-locking - I know the
> name, it's more a
> stuff-to-do-for-making-locking work).

Great!

> What I changed:
> - added EditBegunEvent, AddBegunEvent, EditCancelledEvent, AddCancelledEvent
> - added tests for the Begun-Events
> - I couldn't add tests for the cancelled events - I'm not too familiar
> with mocktestcase not
>  with the z3cform internals - I couldn't figure out what adapters I'd
> have to register for
>  making the cancel-actions work in the tests. I'd be happy if someone
> could look at it
>  and give me hint.

Look at the mocker documentation, or just write your own mocks, or
skip mocks altogether. You just can't depend on Plone in the tests.

> - Alan Runyan mentioned in the plone-cvs-list that begun and cancelled
> is akward and
>  suggested to use Start, Stop, Abort - didn't change that yet

I'm not sure taking English advice from Alan is a good idea... ;-)

I'd prefer the Begun/Cancelled etc names because that'd be consistent
with the AT names.

> Is that ok? Who does the merge once its finished? Should I do it?

Yes, but I'd appreciate a chance to review.

> Then I created a plone.app.lockingbehavior, which is quite simple:
> - it provides a ILocking behavior
> - it registers the eventhandlers from plone.locking on the events of
> plone.dexterity for
>  the ILocking interface
>
> That's working so far. Docu for the lockingbehavior is missing, but
> I'll do that..

Great!

> The only problem is how to protect the edit-form, so that a user
> cannot edit if another
> user is locking the object.
>
> I did quite a simple, but very dirty thing for that:
> I registered an additional event-handler on IEditBegun, which raises a
> Redirect to
> context.absolute_url() if it's locked:
> https://svn.plone.org/svn/plone/plone.app.lockingbehavior/trunk/plone/app/lockingbehavior/handlers.py
> It works well and looks nice (it's a little bit different because the
> user is redirected to the
> default-view, but I think it's well too).

I think this is OK. People who want different behaviour can always customise.

> Is there a better z3cform-solution without creating another form?

Not that I can think of off the top of my head.

Martin

[Baumann Jonas]

Hi Martin

Am 06.12.2010 um 12:55 schrieb Martin Aspeli:

>> - I couldn't add tests for the cancelled events - I'm not too familiar
>> with mocktestcase not
>> with the z3cform internals - I couldn't figure out what adapters I'd
>> have to register for
>> making the cancel-actions work in the tests. I'd be happy if someone
>> could look at it
>> and give me hint.
>
> Look at the mocker documentation, or just write your own mocks, or
> skip mocks altogether. You just can't depend on Plone in the tests.

I could add the tests now - I think I tried to do it too complicated. I'm now
just call the event handler.

>> Is that ok? Who does the merge once its finished? Should I do it?
>
> Yes, but I'd appreciate a chance to review.

I think its ready for a review now, the branch is here:
http://svn.plone.org/svn/plone/plone.dexterity/branches/jbaumann-locking/

I'd be happy if you could take a look at it.

I'll then, as soon as plone.dexterity is ready / released, release the
plone.app.lockingbehavior .

Thanks & Cheers

Jonas

[Baumann Jonas]

Am 03.12.2010 um 11:16 schrieb Martin Aspeli:

I'm getting too confused by all the proposals here. Why don't you take
a look and come up with what you think is the most appropriate
solution, and then describe it in one place. I think the main
constraints are clear:

- plone.dexterity can't depend on any Archetypes or plone.app.* package
- plone.locking can't depend on Archetypes or plone.dexterity
- No z3c.form package should depend on plone.locking
- We want to fire events in the add and edit forms and hook into
them, rather than hardcode locking support
- Locking has to be an opt-in behaviour

Hey

I created a branch of plone.dexterity (jbaumann-locking - I know the name, it's more a

stuff-to-do-for-making-locking work).

What I changed:

- added EditBegunEvent, AddBegunEvent, EditCancelledEvent, AddCancelledEvent

- added tests for the Begun-Events

- I couldn't add tests for the cancelled events - I'm not too familiar with mocktestcase not

  with the z3cform internals - I couldn't figure out what adapters I'd have to register for

  making the cancel-actions work in the tests. I'd be happy if someone could look at it

  and give me hint.

- Alan Runyan mentioned in the plone-cvs-list that begun and cancelled is akward and

  suggested to use Start, Stop, Abort - didn't change that yet

Is that ok? Who does the merge once its finished? Should I do it?

Then I created a plone.app.lockingbehavior, which is quite simple:

- it provides a ILocking behavior

- it registers the eventhandlers from plone.locking on the events of plone.dexterity for

  the ILocking interface

That's working so far. Docu for the lockingbehavior is missing, but I'll do that..

The only problem is how to protect the edit-form, so that a user cannot edit if another

user is locking the object.

I did quite a simple, but very dirty thing for that:

I registered an additional event-handler on IEditBegun, which raises a Redirect to

context.absolute_url() if it's locked:

https://svn.plone.org/svn/plone/plone.app.lockingbehavior/trunk/plone/app/lockingbehavior/handlers.py

It works well and looks nice (it's a little bit different because the user is redirected to the

default-view, but I think it's well too).

Is there a better z3cform-solution without creating another form?

Cheers

Jonas

[Gerhard Weis]

Hi,

wow... that was quick.

There are two things I'd like to ask.

Would it make sense to move the EditBegunEvent, etc... (at least the interfaces). to some generic package? These events could easily be reused, (at least their interfaces), without any framework and won't add an additional dependency wherever they are included.

Does it make sense to add events AddFinished, EditFinished or is cancelled descriptive enough?

Btw. I don't see that Add-Events should trigger locking. If at all, Add-Forms would work on temporary objects, which should be accessible by only one person and only while adding. After hitting add/save, the created object could be locked, by EditBegun. (Did I miss something here?).

Regards,

Gerhard

I would have thought about a solution, that hooks into z3c.form events. E.g. z3c.forms could provide an Event (it does not yet, but may be an option to implement) BeforeWidgetUpdate (or similar). An Event handler could check the lock state, and set the form to read only and add a statusmessage to the display.

(A locking viewlet could provide additional links (like forcefully unlock) and information.).

However, this is rather form- and content framework specific, and needs to be decided in the context of such.

cheers,

Gerhard

>
>
> Cheers
>
> Jonas

[JMehring]

> Would it make sense to move the EditBegunEvent, etc... (at least the interfaces). to some generic package? These events could easily be reused, (at least their interfaces), without any framework and won't add an additional dependency wherever they are included.

You mean like plone.events?? Might be nice to locate all events
together? Would wonder what Martin thinks about this.

> Does it make sense to add events AddFinished, EditFinished or is cancelled descriptive enough?

As Martin mentioned before, using the cancelled name type is to keep
in line with what Archetype already uses. I think it is good to keep
the cancelled description in order to avoid confusion.

> Btw. I don't see that Add-Events should trigger locking. If at all, Add-Forms would work on temporary objects, which should be accessible by only one person and only while adding. After hitting add/save, the created object could be locked, by EditBegun. (Did I miss something here?).

There are things like drafts or custom rendering of forms that come to
mind that could use the events in an add form.

Jason

[Baumann Jonas]

Am 08.12.2010 um 03:46 schrieb JMehring:

>
>> Would it make sense to move the EditBegunEvent, etc... (at least the interfaces). to some generic package? These events could easily be reused, (at least their interfaces), without any framework and won't add an additional dependency wherever they are included.
>
> You mean like plone.events?? Might be nice to locate all events
> together? Would wonder what Martin thinks about this.
>
>> Does it make sense to add events AddFinished, EditFinished or is cancelled descriptive enough?
>
> As Martin mentioned before, using the cancelled name type is to keep
> in line with what Archetype already uses. I think it is good to keep
> the cancelled description in order to avoid confusion.

Adding additional "done"-events is also not necessary, since there are already the zope
events (IObjectModifiedEvent, IObjectAddedEvent), and I'd keep the name of the cancel events.

>
>> Btw. I don't see that Add-Events should trigger locking. If at all, Add-Forms would work on temporary objects, which should be accessible by only one person and only while adding. After hitting add/save, the created object could be locked, by EditBegun. (Did I miss something here?).
>
> There are things like drafts or custom rendering of forms that come to
> mind that could use the events in an add form.

The default dexterity add-forms are called on the container, without using a factory. So the object
is created after submitting a valid add-form - and then it's not necessary to lock it any more.

When using drafts, it already stores the object using the userid as key I thought. So locking
a object in the drafts storage wouldn't be necessary because other user cannot access it
anyway.

Jonas

[Gerhard Weis]

On 08/12/2010, at 12:46 PM, JMehring wrote:

>
>> Would it make sense to move the EditBegunEvent, etc... (at least the interfaces). to some generic package? These events could easily be reused, (at least their interfaces), without any framework and won't add an additional dependency wherever they are included.
>
> You mean like plone.events?? Might be nice to locate all events
> together? Would wonder what Martin thinks about this.

Yes, something like that. I could also imagine, that it might be ok to add these events to plone.locking, as they don't add any additional dependencies. I trust someone with a better overview of the plone.* packages might know what is appropriate.

>
>> Does it make sense to add events AddFinished, EditFinished or is cancelled descriptive enough?
>
> As Martin mentioned before, using the cancelled name type is to keep
> in line with what Archetype already uses. I think it is good to keep
> the cancelled description in order to avoid confusion.

I did not thought it through. I just had in mind whether there may be different event processing necessary for cancel or finish. I did not mean renaming the events. I agree with Martin to keep the AT naming.
However, I can't think of any use case where it might be necessary to have different events for cancel or finish (at least not for locking purposes). And all these events do, is triggering locking or unlocking. So no need to add anything.

>
>> Btw. I don't see that Add-Events should trigger locking. If at all, Add-Forms would work on temporary objects, which should be accessible by only one person and only while adding. After hitting add/save, the created object could be locked, by EditBegun. (Did I miss something here?).
>
> There are things like drafts or custom rendering of forms that come to
> mind that could use the events in an add form.
>
> Jason
>

[JMehring]

> When using drafts, it already stores the object using the userid as key I thought. So locking
> a object in the drafts storage wouldn't be necessary because other user cannot access it
> anyway.

Correct. The AddBegunEvent is just good place as a 'hook' for things
like drafts ;)

Jason

[Martin Aspeli]

On 8 December 2010 08:52, Gerhard Weis <gerhar...@gmail.com> wrote:
>> You mean like plone.events??  Might be nice to locate all events
>> together?  Would wonder what Martin thinks about this.

I suggest you ask on the plone-developers list.

Martin