Sucks, but I've found in a few cases the only way to get what I want is to copy the GWT source (e.g., Horizontal/VerticalSplitPanel) and put it into my code base to make the enhancements I need. (I've not looked at the Tree, so I don't know how much pain would be involved in this route for that widget.)
If you go this route, make sure to first commit the file unchanged (except the package and/or class name) so that if you need to update to a new GWT version, you have a good baseline to compare against. (It sounds like you're in a bit of a time crunch, so perhaps it won't help you, but take a look through some of the bugs which are asking the GWT team to "open up" and stop making all these classes private and/or final so that we are forced to jump through these hoops. E.g.,: http://code.google.com/p/google-web-toolkit/issues/detail?id=1394 http://code.google.com/p/google-web-toolkit/issues/detail?id=2035 http://code.google.com/p/google-web-toolkit/issues/detail?id=2871 etc... ) jay On Dec 23, 7:30 am, "David Hoffer" <dhoff...@gmail.com> wrote: > As you say...I did go looky...at the gwt source and I didn't like what I > saw. They implemented converting events to treeitems with loads of private > data/methods. I would basically have to reimplement huge portions of the > gwt ui code and then somehow prevent my implementation for interfering with > the gwt one. I was hoping I was missing something. > > As for education, I'm the new guy trying to show the BIG guys that gwt can > do what is asked. They tell me its already been done in JSF. I'll bet Flex > can do it, and that's what I'm competing against. There is a time and a > place for education, but this isn't it. I just want a gwt widget that can > do what is asked else we will be programming in Flex. > > I'm currently checking to see if some of the GWT libraries do support this, > I want to use mosaic as its 100% gwt but I get compiler errors when I add it > to my dependencies for some strange reason. > > Thanks, > -Dave > > On Tue, Dec 23, 2008 at 8:05 AM, Reinier Zwitserloot > <reini...@gmail.com>wrote: > > > > > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
