You CAN use it. If you know what you're doing. It wasn't designed to
be particularly easy to use; it was designed to be able to do anything
HTML can theoretically do, even if not all browsers support it.
Contrast this to e.g. ClickListener which is designed to be easy to
use and work across all target platforms.
If you have been asked to do "X, but on the web", and X isn't really
the way webpages are supposed to work, you're supposed to enlighten
the one asking. After all, you're the technical guy, aren't you?
Double clicking is not something you're supposed to do on a web-page.
Ever. Right clicking is similarly not something a web page is supposed
to use (which isn't right clicking at all, it's called 'reacting to a
query for a context menu', though in practice its usually equivalent
to 'user right clicks on something').
You have three options:
1) Figure out how events work for the web (in DOM / JavaScript, not in
GWT). Then dissect a standard GWT widget such as a Button to see how
GWT translates this to java-centric event handling. Then, roll your
own double click and right click listener structure for a new widget
that subclasses Tree.
2) Don't use GWT for this project. It sounds to me like a plain java
webstart app is possibly a better fit for what you're doing.
3) Find a widget set for GWT that does support out of the box what you
want to do. Perhaps GWT-Ext or Ext-GWT or some other add-on GWT
toolkit has what you're looking for.
As you said, 'If google could do it for single click' means you can go
check out HOW 'google' (GWT is an open source community driven
project. Not all contributors are on google's payroll!) did it by
checking out the source. One of the nice advantages of open source
projects, that. Go looky.
On Dec 23, 4:39 am, "David Hoffer" <dhoff...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
