On Tue, Oct 7, 2008 at 11:30 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, Oct 7, 2008 at 10:51 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>
>>>
>>> Would it be typical to addHandler() for a DOM event and *not* want to
>>> sink? If so, then it makes more sense for the names to be uniform, perhaps
>>> even left as is.
>>>
>>
>> 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()?
>
I'm worried people might not realize that they can add dom handlers using
addHandler as well.
>
>>
>>
>>>
>>> While we're talking about names, the term "key" as in "event key" sounds
>>> confusingly like "key" as in "my keyboard has keys". Perhaps there's another
>>> term?
>>>
>>
>> Here are some random suggestions to see if they spark others:
>>
>> 1. Type/TYPE --> addHandler(ClickEvent.TYPE, handler)
>> 2. Meta/meta --> addHandler(ClickEvent.meta, handler)
>> 3. Info/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?
>
>>
>>>
>>> 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"
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
