[TransWarp] On the requirements for "Assembly Events"

[Ulrich Eck]

> The second way is to hand-construct some mechanism of "jump starting"
> components to register themselves.  An example of this is the rough
> 'setup()' method in 'peak.running.commands.EventDriven'.  It needs this
> 'setup()' method so as to ensure that any subcomponents are registered with
> the "reactor" that is used to control the application event loop.

i ran into this problem with my current peak-projects as well: the wxPython
GuiComponent Model and my current Stateful Workflow prototype.

> But this is messy.  It still requires that the component 1) have some
> notion of *which* of its components need to be "set up", 2) have a custom
> method written in each new class that might use components that might use
> components that need to be "set up", and 3) someone must call the first
> "setup" method.
>

yup

[snip requirements]

A formalized way of doing this provided by the framework will help with 
interoperability of components as well. I think the way you described
is pretty straigth forward. to be able to avoid memory-leaks (e.g. wxPython)
i need to destroy components as well. would it make sense to extend
the Assembly events with destroy events as well (this would target to
LifeTimeEvents which i'ld find very useful, if implemented in a good manner) ?

cu Ulrich
ueck <at> net-labs.de