None that I can see. Kelly, I think you pushed for this clampdown. Still
want it?
rjrjr
On Tue, Nov 11, 2008 at 9:41 AM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> I would prefer HandlerManager not be so finalized. I had a real use
> case for creating a version of fireEvent that dealt with DOM-like
> event bubbling for non-DOM events, the effect of freezing
> HandlerManager overrides would deny me the ability of creating a
> EventBubblingHandlerManager. Is there a good reason to prevent
> subclassing and overriding fireEvent?
> -Ray
>
>
> On Tue, Nov 11, 2008 at 8:28 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> > Do you have a proposal in mind? Everything we tightened down we had good
> > reason to do so.
> > On Tue, Nov 11, 2008 at 11:17 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> >>
> >> And as Emily and I just chatted offline, if we're loosening things up
> I'd
> >> rather see us allow folks to provide their own HandlerManager
> implementation
> >> (or wrapper around ours) than just try to predict the one or two hooks
> >> they'll find useful.
> >> rjrjr
> >>
> >> On Tue, Nov 11, 2008 at 7:59 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> >>>
> >>> We have made the fireEvents() final in handler manager and made it
> >>> impossible for users to replace the handler manager in widget, so I
> think
> >>> this change would be necessary to preserve the full spirit of what
> we've
> >>> been doing to upgrade the user's event system.
> >>>
> >>> However, we can tell people to use super-source to replace their
> handler
> >>> manager class instead. It is not as clean of a solution, but it will
> work,
> >>> and we can wait to see if anyone truly howls for this feature and put
> it
> >>> into gwt 2.0 instead, then it can be a cool upgrade instead :-).
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Emily
> >>>
> >>>
> >>> On Tue, Nov 11, 2008 at 10:31 AM, Bruce Johnson <[EMAIL PROTECTED]>
> wrote:
> >>>>
> >>>> Is this really part of the handler update? If this can wait, let's
> wait.
> >>>> We need to wrap up the changes to handlers ASAP.
> >>>> On Tue, Nov 11, 2008 at 9:37 AM, Emily Crutcher <[EMAIL PROTECTED]>
> wrote:
> >>>>>
> >>>>> I've managed to convince myself that it would be a trivial amount of
> >>>>> work to introduce a GwtEventPreview interface into the events package
> and
> >>>>> that the change would be a good one. In specific we would have:
> >>>>>
> >>>>> public interface GwtEventPreview {
> >>>>> boolean onGwtEventPreview(GwtEvent event);
> >>>>> }
> >>>>>
> >>>>> and, in HandlerManager:
> >>>>>
> >>>>> public void setGwtEventPreview(GwtEventPreview preview)
> >>>>>
> >>>>>
> >>>>> Then, in the final fireEvent method, if a preview has been installed,
> >>>>> the event is routed through the preview first and is only fired if
> the
> >>>>> preview returns true.
> >>>>> Can anyone think of any problems with this logic, any reason this
> >>>>> change would take more then a few minutes to create, or
> >>>>> any potentially better solutions which we might want to use instead?
> As we
> >>>>> can certainly wait until GWT 2.0 to introduce something like this if
> we can
> >>>>> think of any conceivable objections.
> >>>>>
> >>>>> Cheers,
> >>>>> Emily
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> "There are only 10 types of people in the world: Those who understand
> >>>>> binary, and those who don't"
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >
> >
> >
> > --
> > "There are only 10 types of people in the world: Those who understand
> > binary, and those who don't"
> >
> > > >
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
