UI Event propagation Design Patterns

[Jason Nerothin]

I've been fiddling around with GWT for a while now for a number of small apps and keep coming across the same problem again and again: How do I propagate UI events like Key clicks back and forth between various widgets (peers) in a widget hierarchy? On the web tier, most of my stuff has been Struts, so I almost reflexively keep a backing model around to share the global state of the application.

An example:

public class MainWidget implements Composite {

    private ApplicationModel model = new ApplicationModel();

    private SubComponentA subA = new WhatsIt(model); // implements ClickListener

    private SubComponentB subB = new ThatsIt(model); // implements ClickListener
   
}

If an event arises in some sub-component of subA, the instance itself can deal with everything it needs to internally to update the view and/or the model. But how do I bubble it up cleanly without requiring the event delegator (MainWidget, presumably, in this example) to have to know all of the ugly implementation details of every WhatsIt and ThatsIt that might comprise it before dispatching the event?

[Peter Blazejewicz]

hi Jason,
I've tried custom events/commands and custom event dispatcher
(modelled after Flex Cairngorm framework: http://labs.adobe.com/wiki/index.php/Cairngorm)
some time ago,
After browser based event occurs it is processed and then custom event
is dispatched via deferred command to other registered listeners
(components/views). It could happen via global dispatcher or via model
or via controller depending on application design,
Event has "target"/"source" property in abstract class to determine
which widget/componetn was the source of such custom event (for
example to avoid self-updates/endless updates). There are concrete
events build for specific tasks that way they could carry additional
data),
this was working well for events/commands pattern, where I was stuck
is the lack of bindings in javascript (i..e on how to update views
after properties/states are changed without writing bunch of custom
listeners),

regards,
Peter

[Thos]

I'd say having a model is the right approach, your event handler
changes the model object, the model object fires an event saying it
has changed and the peers hear the change event and react accordingly.

On Sep 8, 2:51 pm, Peter Blazejewicz <peter.blazejew...@gmail.com>
wrote: