[Insight-developers] Command / Observer / Event

[Lydia Ng]

> Observers should not be able to modify the
> observed Object..... because that will
> trigger a ModifiedEvent while we are still
> in the middle of processing the list of
> events on this object.
>

Why not?

I currently have two applications (one inside the toolkit
and one outside) that rely on this functionality.

[1] I have an observer that externally monitors the progress of
some algorithm. If it satisfies some requirement, the
the observer tells the subject to stop via some
m_Subject->Stop() routine.=20
For example, a GUI updates some display
and when the user is satified they can hit some button
and that will trigger the algorithm to stop nicely.

[2] For the multi-resolution, I think I was Stephen who
suggested it would be nice to have the ability to swap
registration components around, change parameters etc
at the beginning of each resolution level.=20
This is what I have implemented.=20
This is the mechanism which I use to alter parameters
at each resolution level.

I think one definitely have to have a mechanism for the
GUI to talk back and control the filter. So that one
can respond to cancel, change in parameters etc

I have used observers in this way because that is what I thought
they were for. I liked this way of handling the GUI-filter=20
communication because there is good decoupling so I can
fairly easier tied filter to different GUIs.

Please don't take this away dear const meister!

- Lydia

> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> Sent: Wednesday, May 01, 2002 3:32 PM
> To: Insight Developers
> Subject: [Insight-developers] Command / Observer / Event
>=20
>=20
>=20
> Hi,
>=20
> This is a proposal for a change in the
> current structure of the Command/Events
> management in ITK.
>=20
> ------
>=20
> The current implementation of the Observer
> Pattern in ITK is represented in the figure
> below.(Fig.1) The itk::Command classes play
> the role of Observers while the itk::Object
> play the role of Subjects.
>=20
> Subjects send messages to observers by
> invoking Events.
>=20
>  +----------+   Event    +----------+
>  | Subject  |----------->| Observer |
>  +----------+            +----------+
>=20
> (Figure 1.)
>=20
> This was initially introduced as hook where
> GUI interaction could be connected.  The events
> allowed to update the GUI as changes in the
> pipeline occur.
>=20
> Every itk::Object has a list of
> pairs :  <Event, Observer *>
>=20
> These pairs are created in the itk::Object
> by the method
>=20
>     AddObserver(Event, Command *)
>=20
>=20
> When the Subject (any itk::Object) is running
> it may decide to send messages in order to
> inform others about their internal state.
> When the Subject invoke an event, it goes
> through its list of pairs and for every
> event that matches the type of the invoked
> event, it will call the  associated observer
> Execute() method.
>=20
>  +-----------------------+
>  | Subject =3D itk::Object |
>  +-----------------------+
>     |
>     |----< ModifiedEvent, Observer_1 >
>     |
>     |----< ModifiedEvent, Observer_2 >
>     |
>     |----< DeleteEvent  , Observer_3 >
>     |
>     |----< StartEvent   , Observer_4 >
>     |
>     |----< EndEvent,      Observer_5 >
>     |
>=20
> (Figure 2)
>=20
> This mechanisms allows to interconect the
> system yet allowing decoupling since Subject
> don't need to know about observers. The mechanism
> of Events is relatively independent of the
> control of the pipeline. They are only related
> by the fact that some standard Pipeline methods
> InvokeEvents as part of they action.
>=20
> As in the management of Event in GUI's,
> the spirit of the ITK Event is that they
> are just carring information out of the
> pipeline. They are not intended to control
> de pipeline itself.=20
>=20
> Because of the linear execution of the
> events in the list. It is not desirable
> that the Execute() method of an Observer
> could trigger the Invokation of other
> Events.  The execute method should be
> as rapid and passive from the point of
> view of the Pipeling.  For example, we
> should not call and Update() from the
> Execute method of a Command.
>=20
> Imaging for example:
>=20
> Filter1->AddObserver( StartEvent, Command )
>=20
> if the execute method of the command,
> can end up calling directly or indirectly
> the Update() method of Filter1, it will
> enter in an infinite loop with the following
> dialog:
>=20
> Filter says to command: I'm going to start
> Command says to filter: Start.
> Filter says to command: I'm going to start
> Command says to filter: Start.
> Filter says to command: I'm going to start...
>=20
> So,...=20
>=20
> The proposed change in the current mechanism
> is intended to make sure that Observers can
> only be passive elements on the pipeline.
> A first step on this direction is of course:
>=20
>    Const-correctness !
>=20
> Observers should not be able to modify the
> observed Object..... because that will
> trigger a ModifiedEvent while we are still
> in the middle of processing the list of
> events on this object.
>=20
> A more direct way of enforcing pasivness on
> the Observers is not even pass to them the
> pointer to the Subject, only the type of
> event.  In that way the command will just
> blindly execute an action on its side.
> In this options, particular commands that
> actually have to query the state of the
> observed object will have to be created
> as a specialized type of observer and will
> probably keep a internal Constsmart pointer
> to the observed object (the Subject).
>=20
>=20
> Observers that observe multiple object will
> not be selective. The will react in the
> same way to the received Event no matter
> who send it.  If multiple behaviors are
> required, multiple observers should be
> created.
>=20
>=20
> Observers are mostly used in examples
> an in some tests that monitor the progress
> of filter execution.
>=20
> Does anybody see potential conflicts
> with doing these changes ?
>=20
>=20
>=20
>=20
>    Luis
>=20
>=20
>=20
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>=20
>=20