[Zope3-dev] change addform default property setting

[Steve Alexander]

Gary Poster wrote:
> I propose changing the default property setting time in an add form from 
> set_after_add to set_before_add.
> 
> Rationale:
> 
> AFAIK the add event is fired after the object is added to the folder. 
> This is before set_after_add.  Any code that wants to react to this 
> event--an index, for instance--will only see the attributes set up to 
> that point.  set_after_add attributes are unset.  This is inconvenient 
> for cataloging new objects.
> 
> It is very useful to have the ability to set attributes after the object 
> has been contextually wrapped (set_after_add's purpose, I assume) but I 
> propose that this requirement is the exception, not the rule.
> 
> A better solution that I'm not sure how to implement: the add event is 
> postponed until after set_after_add.
> 
> Thoughts?  Corrections?

With the current model, you would get an Added event after adding, and 
then a Changed event after set_after_add.

With some sort of queued catalogue, an Added followed immediately by a 
Changed can be combined into just an Added. (At least, for some 
purposes, this combining is valid. For other purposes, it is not.)

Having said that... what is the use-case for set_after_add? If it really 
does need to be "after add", then I expect it is because these 
attributes require that when they are set, the object is in context, 
with a name in the context-wrapper's dict.
Due to the way containers work, you can only know the correct name after 
an object has been added. The container's decorator is responsible for 
firing the ObjectAdded event. So, you need to expect both an ObjectAdded 
event and an ObjectChanged event.

If the setting attributes requires only a context parent, and the 
attributes don't care about the name in context, then you could wrap the 
object in the context of its prospective container before actually 
adding it. However, this seems like an odd way of doing things.


Thoughts:

   Don't do it. :-)

I suggest focusing on why receiving an Added event followed by a Changed 
event is a problem.

One solution is to use (or port to Zope 3) the QueuedCatalog product.

Another solution would be an EventChannel that queues events during a 
transaction, and combines and fires them at the end of the transaction. 
This is what my Zope 2 TransactionAgents product is for.
To make this work without monkey-patches, there needs to be a 
"transaction about to commit" hook. Interested parties can register a 
callback with this hook.

There are other things you can do with such a hook, such as enforcing 
constraints and triggering events, but I'll save that for some other 
proposal.

--
Steve Alexander