Actually, we also should get some good feedback from the first gwt 1.6
milestone. That will also help us calibrate how important this feature is
to folks, and we can always introduce something like it after the milestone
if it seems to be very much missed.
On Tue, Nov 11, 2008 at 11:36 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> 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"
>>
>
>
--
"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
-~----------~----~----~----~------~----~------~--~---
