@John: hm2 could indeed handle onOpen and hm1 would never get a chance to
notify its registered handlers :(
So I'd gues the event has to be pushed down in all cases ... which pretty
much takes us to "one" HM setup.

I also think that createHM is enough.

In general, though components usually have setters/getters for their
properties, a good API makes obvious where the developer has to interveene
(in the setters or getters) in order to customize.

In particular, if we had a createHM, wouldn't it defy the purpose to have an
(overridable) getHM. In other words, why not have getHM replace the
createHM?

Andi


On Wed, Feb 10, 2010 at 10:54 AM, John Tamplin <[email protected]> wrote:

> On Wed, Feb 10, 2010 at 10:27 AM, Andi Mullaraj <[email protected]>wrote:
>
>> I believe changing HMs mid stream is dangerous:
>>
>> 1. Say your (nav & edit) widget fires events that are common to both modes
>> (i.e. a simple onOpen) and the widget is by default in nav mode
>> 2 Say A registers an onOpen handler (which gets added to hm1 -- the
>> default HM)  then later switches to edit mode (and hm2 kicks in)
>> 3. A will not see the onOpen events while on edit mode!
>>
>> If your nav & edit widet stays always in one mode, then createHM would do
>> the trick. But if it switches modes you have to make sure there is no
>> overlapping sets of events ...
>>
>
> Another option to achieve this with potentially less danger is to maintain
> a stack of HandlerManagers.  If one HM doesn't handle an event, it goes down
> to the next one.  Then, if you want to have some modal event handling logic,
> you push a new HM on the stack with its own set of event handlers.  When you
> are done with the modal logic, you pop it off the stack.  Event types not
> handled by the modal event handler fall through to the main one, so in your
> example onOpen would still get handled properly.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to