The only proposal I have in mind right now is that we stop messing with
stuff and get the branch merged.
rjrjr
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
-~----------~----~----~----~------~----~------~--~---
