I'd say that if you wanted to implement a HandlerManager stack, it
would probably be best to do that internal to the HandlerManager,
rather than forcing a Widget to know how events are handled.
Assuming that is possible given the current Widget implementations
(others more expert than I would know this, probably), the only API I
would want is createHandlerManager(). I could then manage how that
more complex HandlerManager is dealt with.
While we're on the subject... if you're providing this factory method,
I would rather see a well-documented interface to implement rather
than a semi-documented implementation of which I would probably be
overriding every method.
just my .02
On Feb 11, 11:05 am, Ray Ryan <rj...@google.com> wrote:
> This conversation keeps getting complicated by discussions of policy. I'm
> just trying to make it possible for widgets we haven't thought of yet to
> define policies of their own.
>
> E.g., to temporarily switch between modes that change the set of events they
> source, copying some handlers or not if that's appropriate (perhaps in mode
> B I simply am not a source of the events that would happen in mode A.
> Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try
> out a singleton HM (I wouldn't, but why should I stop you from trying it
> out).
>
> I think JohnL has hit the sweet spot with:
>
> /**
> * Called by default implementation of {...@link #getHM}
> * to lazily instantiate the HM for this widget.
> */
> protected HM createHM();
>
> /**
> * All access to the widget's HM must be made through this method.
> * It is an error to cache the object returned. The default implementation
> * returns the result of {...@link #createHM} the first time it is called.
> */
> protected HM getHM();
>
> If I override getHM(), I have the option to call the normal createHM() to
> get whatever HM the widget normally uses. Or not. If I override createHM() I
> can provide a custom implementation, or wrap the normal one, without having
> to re-implement the lazy instantiation mechanism.
>
> Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
