[gwt-contrib] Re: A rose by any other name (what to call addHandlersAndSink)
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.
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)
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
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: A rose by any other name (what to call addHandlersAndSink)
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
-~--~~~~--~~--~--~---
[gwt-contrib] Re: A rose by any other name (what to call addHandlersAndSink)
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
-~--~~~~--~~--~--~---
[gwt-contrib] Re: A rose by any other name (what to call addHandlersAndSink)
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
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
