The fireEvent method is currently final because our
addHandler/removeHandler is relying on our version of fireEvents being
called because we are handling concurrent adds and removes using an internal
counter managed by fireEvent.
By the way, as the GwtEventPreview interface is meant to address just this
use case, would it work in your case? Not that we are implementing it right
now, but it would be good to know if we have a working solution.
Also, how important is having a protected widget createHandlers() method?
Currently I've been talked out of it under the hypothesis it can be added
later.
On Tue, Nov 11, 2008 at 12:42 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> 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"
>> >
>> > >
>> >
>>
>
>
> >
>
--
"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
-~----------~----~----~----~------~----~------~--~---