Alright, lets go with createHandlerManager() for now. Thanks for all the
feedback.
@sven -
Would you like to update the patch by reverting the getHandlerManager()
method back to a package protected method? If you don't get to it for a few
days, I'll can do it for you.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, Feb 11, 2010 at 9:39 PM, Nathan Wells <nwwe...@gmail.com> wrote:
> 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
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
