Re: Object created events

On Wed, 27 Sep 2006 08:32:45 -0700, Martin Aspeli <[email protected]> wrote:

>
> Hi Kapil,
>
>
> Kapil Thangavelu wrote:
>>
>> i think this needs a proposal and to be thought through rather than code
>> just landing.
>>
>
> Well, there was a big discussion and this is the continuation of that
> discussion. :)
>

aye, like diving onto fish tail, and finding a whale ;-)

>
>
>> i think created events are the wrong semantic, z3 fires them for class
>> instantiation/factory creation, and you want them for object
>> initialization in context, which are different use cases. i'd rather  
>> some
>> subclass of modified event for initializated that fired only once.
>>
>
> That is exactly what I proposed:
>
>  - IObjectCreatedEvent when the type is first created (in the  
> constructor,
> or initializeArchetype)
>  - IObjectModifiedEvent on regular modifications
>  - IContentInitializedEvent, inherits from IObjectModifiedEvent and is  
> fired
> (instead of IObjectModifiedEvent) on the first initialisation.
>

that sounds good, one comment on createdevent at end.

>
>
>> also the point that rocky makes that this stuff shouldn't be in base AT
>> classes, is valid imho, z3 events are typically fired by view code and
>> putting inline with method calls, means like some serious headaches for
>> existing software. for example as soon you add in hacking in a few
>> modified events and hook up an indexer to it, you now have the fragile  
>> at
>> manager_after add dance, and api usage generating events, causing
>> indexing, resulting in extraneous duplicate indexation calls, which just
>> makes the system harder to assume any deterministic behavior for.
>> basically lots of code thats using the api isn't expecting to generate
>> events, is suddenly going to be generating events, and unless we have a
>> coherent story about moving AT to it, doing it piecemeal in adhoc  
>> fashion
>> is likely to be dentrimental and destabilizing, imo.
>>
>
> I think these are valid points, but there are also clear benefits to  
> having
> a few sane, basic lifecycleevents - this stops us hacking into the API in
> different ways.

agreed, its a good incremental step for any further work, and leaving it  
in processForm
is the analogous at view machinery.


>
> The proposal here is that we fire in processForm() in the first instance,
> which for all intents and puropses *is* view code. It's just that before
> Zope 3 and Five came along, view code was stuffed into methods on the the
> content class itself. processForm() is not really an API that people use
> from non-view code, so I think this is safe.
>
> About the creation event, initializeArchetype() ought to be safe, IMHO,  
> but
> other ideas are much appreciated.
>

if we want to move to z3 concepts, i'm not sure thats its a good idea to  
have a divergent concept here of the same name, ie. createdevent, which in  
z3 is typically sans context (ie unattached ), and here we would take it  
to mean attached and fired from initializeArchetype, ie. a lot of  
lifecycle stuff has already happens between object instantion, adding to  
the graph (firing add events), and getting an objectcreatedevent in that  
case. i think it might be better to just choose a separate name to denote  
the event.

so instead a separate ObjectAttachedEvent for initializeArchetype, and  
have the factory do ObjectCreatedEvent.

cheers,

kapil

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV