On Tue, Oct 7, 2008 at 12:53 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>
>>
>>>>> It would typically be the case that you would want to sink, however
>>>>> this is not always true, so we want users to have the option of whether to
>>>>> sink or not.
>>>>>
>>>>
>>>> addDomHandlerAndSink()?
>>>>
>>>
> If we are depending upon javadoc, what about just calling it
> addDomHandler(DomHandler handler) with javadoc directing people to use
> addHandler if they don't want to sink the events?
>
I like it.
>
>
>
>
>
>>
>>>>> 1. fo/INFO --> addHandler(ClickEvent.INFO, handler)
>>>>>
>>>>> +1 for type. It's a shame you can't just use the class literal
>>>>
>>> ClickEvent.type or ClickEvent.TYPE?
>>>
>>
>> If it's a constant, it should be upper.
>>
>
> So +1 for TYPE . I could see arguments for ClickEvent.type as it is the
> moral equivalent if ClickEvent.class, which is why I asked.
>
>
>
>
>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> On Mon, Oct 6, 2008 at 5:36 PM, Emily Crutcher <[EMAIL PROTECTED]>wrote:
>>>>>>
>>>>>>> Here is the current doc on it, to give context:
>>>>>>>
>>>>>>> /**
>>>>>>> * Adds a native event handler to the widget and sinks the
>>>>>>> corresponding
>>>>>>> * native event.
>>>>>>> *
>>>>>>> * @param <HandlerType> the type of handler to add
>>>>>>> * @param key the event key
>>>>>>> * @param handler the handler
>>>>>>> * @return [EMAIL PROTECTED] HandlerRegistration} used to remove the
>>>>>>> handler
>>>>>>> */
>>>>>>> protected <HandlerType extends EventHandler> HandlerRegistration
>>>>>>> addHandlerAndSink(
>>>>>>> DomEvent.Key<?, HandlerType> key, final HandlerType handler) {
>>>>>>> sinkEvents(key.getNativeEventType());
>>>>>>> return addHandler(key, handler);
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> On Mon, Oct 6, 2008 at 5:35 PM, Emily Crutcher <[EMAIL PROTECTED]>wrote:
>>>>>>>
>>>>>>>> The purpose of the new method "addHandlersAndSink" is to allow users
>>>>>>>> to add a DOM handler and sink the necessary event in one easy step.
>>>>>>>>
>>>>>>>> The reason we, the GWT team, care about this is because
>>>>>>>> traditionally, with the two call separated everyone, including us,
>>>>>>>> will tend
>>>>>>>> to sink the events in the constructor rather then when a handler is
>>>>>>>> actually
>>>>>>>> added. This can degrade performance significantly for small widgets,
>>>>>>>> so we'd
>>>>>>>> like to encourage our developers to do the fast/efficient thing
>>>>>>>> instead.
>>>>>>>>
>>>>>>>> addHandlersAndSink has the advantage that when you autocomplete to
>>>>>>>> find your widget methods, it appears directly under addHandlers.
>>>>>>>> However,
>>>>>>>> it sounds somewhat awkward, so a better name might be in order, hence
>>>>>>>> this
>>>>>>>> post...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> "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"
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> "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
-~----------~----~----~----~------~----~------~--~---