Hi Reinier,
So are you saying I can't use EventListener to somehow implement
double/right click support in Tree widgets and convert the Event to a
TreeItem?
Moreover are you saying that double/right click support cannot be
implemented using GWT? Unless I want to start over and re-implement
widgets?
I understand what I am looking for is very Swing/desktop app centric rather
than the norm on the web. However that is exactly what I have been asked to
do.
If you had to had to have double/right click Tree widget support how could
you/I get the TreeItem the user operated on? If Google could do it for
single click I don't see why the same is not possible for other operations.
-Dave
On Mon, Dec 22, 2008 at 4:49 PM, Reinier Zwitserloot <reini...@gmail.com>wrote:
>
> 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<http://examples.roughian.com/index.htm#Listeners%7ESummary>
> > 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
-~----------~----~----~----~------~----~------~--~---
