1) You can use something called 'anonymous inner classes'. google it.
They look something like this:
someButton.addClickListener(new ClickListener() { public void onClick
() {
/* code that runs when someButton is clicked goes here. */
}});
This does produce 2 class files, but this is an utterly irrelevant
implementation detail of the JVM. GWT doesn't even give a crap about
these; it generates JS files directly from the java sources, and the
class files are there only because some IDEs don't work well without
them, and the hosted mode debug tool needs them. Whining about this is
pointless, as its a fact of life of the JVM platform. It also seems a
bit pointless to whine about: Who cares about how many class files are
involved?
2) the web doesn't work with generic 'I want every event ever' style
event catching. You can only sign up for a few events. The ones GWT
has nice abstractions for (all the 'specific' listeners) are the ones
that work reliably and similarly on all supported GWT platforms. There
are a select few event types that are non-standard and aren't
generally available on GWT's widget (the most famous one is probably
doubleclick), and there are a few widgets that don't have an
addXListener for something they do support. EventListener and the
Event class are LOW LEVEL SUPPORT classes - you do not use them in
normal code, only in library code. They are used by GWT's own widgets.
You should use them if you're building your own widget from scratch
(but not when you're compositing them from other GWT widgets). If you
aren't doing that, then you shouldn't be using them. They aren't drop
in replacements to do 'catch all events' code.
In general, you should not use the stuff that isn't supported. If,
however, you must, then you can. This involves messing with the DOM.*
utility methods and generally means you need to know what you're
doing. Remember, GWT is a *LEAKY* abstraction. Using GWT when you
don't have a clue about how html, the dom, and javascript work, is not
a supported use case. GWT is useful because it makes web development
easier. That's a long way of saying: Tough cookies, go learn how the
web works, then come back.
Once you've figured that all out, this is how you can hack GWT:
1. use DOM/Widget.sinkEvents to set up a listener on the DOM side for
the specific event you're interested in.
2. Use the EventListener raw interface / override onEvent from the
Widget class and check the Event code to know what just happened. The
'Event' class is a javascript/java interactivity tool, just like the
JavaScriptObject class. You are NOT supposed to do anything with it in
java code; you pass it into JSNI methods and then the JSNI code does
something with it. This interface also provides you with a few useful
parameters, such as the sending object.
3. As a general rule, using one event listener to handle events coming
from multiple objects, is bad design. Use as many anonymous inner
classes as you need, instead. This is only acceptable in certain
situations that involve arrays of 100% similar widgets (such as a blog
engine where you have a list of checkbox widgets, one for each tag,
where the tags on any given post are completely dynamic - for example,
set by the user when he wrote the post. Then it can make sense to have
just one event listener for the whole lot, and check which widget
caused the event to respond appropriately).
4. When using anonymous inner classes for event handlers with more
than one method (such as the keyboard listener which has keyUp,
keyDown, keyPress), but you only care about one of those, use the
XListenerAdapter class instead of the interface. Make sure you use the
@Override annotation on the one method you're overriding when you do
this, or bad things happen when you typo the method name
(specifically: nothing happens at all, which means you have to go on a
bug hunting spree to figure out why nothing is happening. It can take
a while to realize you typoed the method name. With an @Override in
place, the compiler will refuse to compile your code right from the
get go. Much easier to find that mistake now.)
Example situation: I have a cancel button and an ok button.
DO THIS:
cancelButton.addClickListener(new ClickListener() { public void onClick
(Widget w) {
dialog.close();
Messaging.flashWarning("Sign-up cancelled.");
}});
okButton.addClickListener(new ClickListener() { public void onClick
(Widget w) {
okButton.setEnabled(false);
dialog.showSpinner();
sendRegistrationRequest(emailBox.getText(), new
RegistrationRequestHandler() {
@Override public void requestAccepted() {
dialog.close();
Messaging.showMessage("Congratulations! You've signed up
to our service!");
}
@Override public void requestDenied(String reason) {
dialog.close();
Messaging.showError("Whoops - we can't process your sign
up request, because " + reason);
}
});
}});
do NOT do:
myClickListener = new MySignupDialogClickListener();
cancelButton.addClickListener(myClickListener);
okButton.addClickListener(myClickListener);
and then in MySignupDialogClickListener:
public void onClick(Widget w) {
if ( w == SignupDialog.getInstance().okButton ) handleOkButton();
else if ( w == SignupDialog.getInstance().cancelButton)
handleCancelButton();
}
That last one is very ugly, a massive waste of time (it violates DRY
principle much more), separates two related code snippets for
absolutely no good reason whatsoever, is a pain to add new things to,
and did I mention it was ugly? Don't do it.
On Dec 22, 4:37 am, "David H. Cook" <david.hubert.c...@gmail.com>
wrote:
> The more code I implement and the more event-related APIs
> I look at in GWT, the more confused I get. After
> looking at complete examples about 'listeners' on website such
> as:http://examples.roughian.com/index.htm#Listeners~Summary
> or posts in this group, I conclude that the most general
> is an 'EventListener', because then I can get at ANY/ALL events
> that I might be interested in, as it's method gets 'Event e'
> as an input param. But, what seems to me like
> a real NEGATIVE is that I must 'extend' (sub-class) an object
> to use EventListener, right?
>
> Now, if I only care about a 'click', then I do NOT need to extend,
> because there are 'clicklisteners', which listen for just ONE event
> type...'click'. But, if I want, say, 'double-click', well, there
> are NOT any 'double-click' listeners, so it seems that I'll need
> to use the more general EventListener.
>
> That would be reasonable/acceptable if there was just
> ONE object that I wanted/needed to extend in a given app.
> But, let's say, I care about 'doubleclicks' from 3 different
> objects in the same app...anchors, tabs, and images.
> (Maybe not the best examples, but bear with me.)
> So, it seems that now I need to extend three objects, so I'll
> need 3 java classes (and thus, ...3 FILES...one class per file).
> [Some posts/examples mention 'widget builders' as a separate
> class of developer. But, I don't want to build new 'widgets'...
> I just want a write a simple app.
>
> Somehow, the APIs seem to be making things unnecessarily 'complex',
> when I compare this to how easy it was to implement events
> in javascript language (before I started using GWT). And, its
> beginning to seem like the designers of the event-model/event-apis in
> GWT
> might have miss-designed the APIs?! (I wasn't around at the
> beginning, so I don't know how the event-APIs looked in version 1.00.)
>
> Both the author of roughian website and other posters all seem to
> bemoan
> this need to extend, but all say it is necessary. For example,
> roughian
> says:
>
> [Notes:
> This is something you should only use if you are subclassing a widget
> - it's not much use otherwise,
> you can't addEventListener() to anything I'm aware of.
> So, as a builder of widgets, you'd use this to pick up events and use
> them in ways
> that you can't do with the ordinarily supported event interfaces]
>
> Clearly, I (and others?) must all be missing something. Where have I
> gone wrong?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
