On Tue, Oct 7, 2008 at 11:36 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>
> 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.
>
I'd think JavaDoc can take care of that. This name makes it clear that this
is the preferred way to deal with Dom handlers (and that it's irrelevant to
other kinds), and the doc can provide the fine print.
>
>
>
>>
>>>
>>>
>>>>
>>>> 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?
>
If it's a constant, it should be upper.
>
>
>
>>
>>>
>>>>
>>>> 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
-~----------~----~----~----~------~----~------~--~---
