Reinier -
Thank you, thank you, for the EXCELLENT explanation in
your posts to this thread. I totally get it now.
I like especially that you point out that, given GWT objectives
and constraints, it is NOT necessarily the right tool for
all webapps.
I guess I made the correct decision, back when I finally just
changed my design to use the GWT APIs in a straight-forward
way (rather than 'hack' down in and expose leaks.
Now I get your earlier reference to 'LEAKY'.
One last thing someone could do is to PUBLISH this sort of
perspective...i.e. put it in overview docs where new prospective
developers are apt to find it.
Cheers...
Dave [the base-noter]
On Dec 23, 8:45 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> As I said, "Event" is a low level class. You don't use it from java
> code, you use it from JSNI code. Another low level 'class' is the DOM
> class. It is a repository of loads of static utility methods (you
> don't ever do 'new DOM()', you just call DOM.someMethod()). Anything
> you can do with Event objects without resorting to JSNI is done with
> the various methods in the DOM class that start with 'event'. For
> example, to get the thing that the event happened for, you use
> DOM.eventGetTarget(Event e). However, this returns an Element, which
> is another low level class. Elements, just like Events and
> JavaScriptObjects, don't have any useful methods for java GWT code.
> They are plenty useful when transported to JSNI methods, and there are
> plenty of methods in the DOM class that work on Elements. Generally,
> widgets CONTAIN an Element, so its not easy to go from Element to the
> widget it belongs to, which is why you're having so much trouble.
>
> Screwing about with DOM and Element will result in GWT projects that
> leak memory, especially on IE, unless you -really- know what you are
> doing. For example, if you add a listener yourself, you have to be
> very careful in removing it at the right time or the listener, and in
> turn every object it points at (and every object those objects point
> at, etcetera) are stuck in the browser forever (well, until the user
> closes the browser or the window with your app in it, but for a
> webapp, that's what 'forever' means, really).
>
> On Dec 24, 1:57 am, "David Hoffer" <dhoff...@gmail.com> wrote:
>
> > In my case I need to support right click in Tree widgets so the global
> > option doesn't help. I'm willing to live with limited browser support if I
> > can convert the Event returned via onBrowserEvent() to a TreeItem.
>
> > -Dave
>
> > On Tue, Dec 23, 2008 at 3:49 PM, lukehashj <bobwazn...@gmail.com> wrote:
>
> > > Those lego pieces are the special get a box of em for 20 bucks pieces
> > > -
>
> > > To implement this functionality I would use a little bit of JSNI and
> > > the onContextMenu functionality.
>
> > > Open up your module's main .html file and locate your body element.
> > > Add onContextMenu='someJavaScriptFunction()' to it.
>
> > > Next, add a <script type='text/javascript'>function
> > > someJavaScriptFunction(){ execute JSNI here }</script> to the inner
> > > HTML of the head element and you are set!
>
> > > If you've not read about JSNI, here is a good resource:
> > >http://code.google.com/support/bin/answer.py?answer=75695&topic=10213
>
> > > Obviously, this is a global solution - usually used to display an
> > > alternate context menu. If you're trying to implement right-click for
> > > a particular element that's a little bit more tricky and less reliable
> > > across browsers.
>
> > > On Dec 23, 3:23 pm, "David Hoffer" <dhoff...@gmail.com> wrote:
> > > > Sounds good, I'll try that for DoubleClickEventListener.
>
> > > > What lego pieces would you use to implement RightClickEventListener?
>
> > > > -Dave
>
> > > > On Tue, Dec 23, 2008 at 2:59 PM, lukehashj <bobwazn...@gmail.com> wrote:
>
> > > > > If you want the double-click event, create a DoubleClickEventListener
> > > > > that extends ClickListener. When the click event is fired a timer is
> > > > > started - if they click again before the timer executes, the
> > > > > onDoubleClick event fires. Otherwise, it's just treated as a single
> > > > > click. Using this mechanism, you can adjust the speed at which the
> > > > > user must double-click for you to get the event. This can be helpful
> > > > > in improving your websites accessibility (ease of navigation, etc).
> > > > > This also allows you to add a DoubleClickListener to any class that
> > > > > implements the SourcesClickEvents class.
>
> > > > > If you are rolling your own horizontal/vertical panels you're
> > > > > approaching composition from the completely wrong direction.
> > > > > You should probably create a class that extends Composite but includes
> > > > > all the functionality that you would have added to the base GWT class
> > > > > (es) and calls initWidget(on a horizontalPanel). Or, simply extend the
> > > > > GWT class and add the missing/desired functionality to it.
>
> > > > > The GWT widget/event classes are like legos - use the small parts to
> > > > > build a greater cohesive structure. Don't plan on the legos coming out
> > > > > of the box preassembled!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
