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
-~----------~----~----~----~------~----~------~--~---
