From: Wolfgang Rostek on
Hi NG,

in my Swing rich client application I'm
using the presentation model (PM) approach.
Some event flow is not clear to me how
to make it right.

The coarse grained loop I'm trying not to
violate is the following

1. A user action on the client is the basic
loop and will finally result in a new state
of the client and gets idle again.

2. The user action is working on a widget
which will set its peer attribute of the PM.
These setter methods will neither trigger a
notification nor calculate dependent modifications
of the PM. This is done in the next step.

3. At the end of the user action a single
update(reason) is called on the PM. This
will elaborate the PM to a valid new state. It
may be necessary here to contact the domain
model and start some asynchronous processing.

4. Now the PM is stable again and a notification
(reason) is sent to all views. To release the
emitter this notification will run in its own
runnable event enqueued to the system event queue.

5. All views have to sync to the PM in their reload
method. They are not allowed to start further PM
modifications during this notification.

The problem I'm running into is the behaviour of
complex widgets. To figure out an atomic user
action for the cycle above is sometimes not easy.

Here my concrete example

A treetable has a selection for its rows and an
expand/collapse state for its tree nodes. Both
information are of interest for the PM and tracked
there.

By clicking into an expandable node the user triggers
the following sequence. First a row selection is
fired. A second subsequent event is the expand
event.

How to handle that as a single atomic action for
the PM?

The selection is known as a stand-alone event to
the PM as well. After calling the setter an update
and notification would be triggered. But as stated
above I would like to have only one update/notification
for a user action (expand in this case).

A second question is the expand event. After setting
the expand state of the node the inner working of
the treetable will immediately ask the children for
visibility. But the PM has not yet elaborated the new
state of the child nodes. This would be calculated in
the update(expand) call to the model. Should I break
this inner working and postpone the treetable expansion
to the later reload call? Or should I make the setter
methods aware of doing this work already?

Drag&Drop seems to raise similar problems mentioned in
a Dolphin/MVP paper.

Any advice how to handle it well?

Thanks in advance
Wolfgang R.