Re: What am I misunderstanding about the event model?

[David H. Cook]

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  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"  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  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 function
> > > someJavaScriptFunction(){ execute JSNI here } 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"  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  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
> >

Re: What am I misunderstanding about the event model?

[Ian Petersen]

On Tue, Dec 23, 2008 at 7:53 PM, David Hoffer  wrote:
> So its not a notification problem its a data access problem.  I have looked
> at how the Tree control does this for single clicks but they made all the
> data & methods private so I can't use them.
>
> If you know a way to do this please advice.

Use the violator pattern.  (I think--I've never seen "violator
pattern" defined, I've just seen it used and I assume it means what I
think it means.)

Suppose you have a library class:

package com.example.library;

public final class LibraryClass {

  public void mungeSafely() {
if (!safe()) {
  throw new UnsafeException("Not safe to munge!");
}

mungeDangerously();
  }

  private void mungeDangerously() {
// munge munge
  }
}

And suppose you want to mungeDangerously() from outside LibraryClass.
You can do this:

package com.example.app;

public class LibraryUser {

  public void tryToMungeDangerously(LibraryClass o) {
// you could implement this method as a violating JSNI method
// directly because it does nothing but delegate, but the extra
// method invocation is probably worth it if the surrounding code
// is non-trivial
mungeDangerously(o);
  }

  private static native void mungeDangerously(LibraryClass o) /*-{
// the doubled parens at the end of the next line are not a typo
// see the JSNI docs for details
o.com.example.library.LibraryClass::mungeDangerously()();
  }-*/;
}

JSNI doesn't obey Java visibility rules, so you can violate them in a
controlled manner by writing JSNI methods like the one above.  (Note,
I typed the above code directly into this email, so check the JSNI doc
that lukehashj pointed to if you run into trouble.)

I haven't looked at the code you're trying to reuse, so I have no idea
if the "violator pattern" really solves your problem or if it just
pushes the dirt around.  Of course, this approach really is a
work-around, not a solution, but I find it a bit cleaner than
maintaining a parallel implementation while waiting for an
officially-sanctioned release of GWT that does what you want.

Ian

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: What am I misunderstanding about the event model?

[Reinier Zwitserloot]

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"  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  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 function
> > someJavaScriptFunction(){ execute JSNI here } 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"  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  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
-~--~~~~--~~--~--~---

Re: What am I misunderstanding about the event model?

[David Hoffer]

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  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 function
> someJavaScriptFunction(){ execute JSNI here } 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"  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  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
-~--~~~~--~~--~--~---

Re: What am I misunderstanding about the event model?

[David Hoffer]

Jay,

Yes, in my case at least, I want to use onBrowserEvent() like you say
but...and its a show stopper...I am doing this in a Tree widget.  Obviously
what someone cares about in this context is the TreeItem the user right
clicked on.  The problem is there is no way (that I have found yet) to
convert the Event object returned in onBrowserEvent() into the TreeItem the
user cares about.

So its not a notification problem its a data access problem.  I have looked
at how the Tree control does this for single clicks but they made all the
data & methods private so I can't use them.

If you know a way to do this please advice.

-Dave

On Tue, Dec 23, 2008 at 5:04 PM, jay  wrote:

>
> Perhaps I'm missing something, but why JSNI? Why not just override
> onBrowserEvent(), and use DOM.eventGetButton(Event) to check for
> Event.BUTTON_RIGHT?
>
> Can't you use the DOM.eventGetButton() to check for Event.ONDBLCLICK ?
>
> Please...if I'm wrong let me know... I've been fairly successful with
> my usage of GWT, but I'm always looking to learn how to do things
> better.
>
> jay
>
>
> On Dec 23, 2:49 pm, lukehashj  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 function
> > someJavaScriptFunction(){ execute JSNI here } 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"  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 
> 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
-~--~~~~--~~--~--~---

Re: What am I misunderstanding about the event model?

[jay]

Perhaps I'm missing something, but why JSNI? Why not just override
onBrowserEvent(), and use DOM.eventGetButton(Event) to check for
Event.BUTTON_RIGHT?

Can't you use the DOM.eventGetButton() to check for Event.ONDBLCLICK ?

Please...if I'm wrong let me know... I've been fairly successful with
my usage of GWT, but I'm always looking to learn how to do things
better.

jay


On Dec 23, 2:49 pm, lukehashj  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 function
> someJavaScriptFunction(){ execute JSNI here } 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"  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  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
-~--~~~~--~~--~--~---

Re: What am I misunderstanding about the event model?

[lukehashj]

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 function
someJavaScriptFunction(){ execute JSNI here } 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"  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  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
-~--~~~~--~~--~--~---

Re: What am I misunderstanding about the event model?

[David Hoffer]

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  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
-~--~~~~--~~--~--~---

Re: What am I misunderstanding about the event model?

[lukehashj]

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
-~--~~~~--~~--~--~---

Re: What am I misunderstanding about the event model?

[jay]

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"  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 
> 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"  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  > >wrote:
>
> > > > 1) You can use something called 'anonymous inner classes'. google it.
> > > > They look something like this:
>
> >

Re: What am I misunderstanding about the event model?

[David Hoffer]

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 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"  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  >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
> > > doublecl

Re: What am I misunderstanding about the event model?

[Reinier Zwitserloot]

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"  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 
> 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:
>
> 

Re: What am I misunderstanding about the event model?

[David Hoffer]

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 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 fin

Re: What am I misunderstanding about the event model?

[Reinier Zwitserloot]

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:

myClickListene

Re: What am I misunderstanding about the event model?

[David Hoffer]

In my case I do want to subclass and handle the EventListener interface
because I care about single/double/right clicks in Tree objects.  However
how can I convert the Event returned via onBrowserEvent() into a TreeItem?

The interface is quite useless unless it is possible to convert the thing
returned (event) into something users care about i.e. TreeItem in this
case.  How can this be done?

-Dave

On Mon, Dec 22, 2008 at 5:20 AM, David H. Cook
wrote:

>
> Jason -
>
> You wrote:
> "The problem with the standard DOM EventListeners is that only one
> listener can be attached to an
> Element. The other problem is that a custom Widget may be required to
> listen for a sequence of
> low-level events in order to trigger a single high-level event (think
> MOUSEDOWN/UP/MOVE in relation
> to itemDraggedAndDropped())"
>
> Yes!   I agree totatlly! There are nothing BUT problems with the event
> model.
> So, with those shortcomings, why did they implement it that way?
>
> Like the 'roughian' man said so succinctly:
> "You can't addEventListener() to anything I'm aware of."
>
> That's my criticism in a nutshell!  So, why didn't they implement it
> that way?
> Then they wouldn't have even NEEDED all those other (foolish) Listener-
> APIs
> with all their shortcomings!
>
> You wrote:
>  "If you are extending the classes over and over again..."
>
> NO, I'm NOT!  I don't like it that I need to!  So, I refuse.
>
> In fact, what I found myself doing was to change my whole design (from
> what I had when I first implemented it in the old javascript-model) so
> that
> I am NOT implementing DBL-CLICK,  because of the need to sub-class.
>
> [I found a thread a week ago or so, where someone found that in the
> soon-to-be
> released GWT 1.60, there was some refactoring of event-stuff, and I am
> hoping
> against hope that they were ripping out ALL the event-routines, and
> simplifying,
> but of course, they aren't.  The community would be in an uproar.
> (Except for me.!)
> I'd welcome it with open-arms, as I have just one small app written in
> GWT, and
> would be more than happy to re-write all the event-stuff, if they were
> to redesign
> it totally.]
>
>
>
> On Dec 22, 3:04 am, Jason Morris  wrote:
> > The GWT event model is a close relation of the standard Java event model.
> >
> > The problem with the standard DOM EventListeners is that only one
> listener can be attached to an
> > Element. The other problem is that a custom Widget may be required to
> listen for a sequence of
> > low-level events in order to trigger a single high-level event (think
> MOUSEDOWN/UP/MOVE in relation
> > to itemDraggedAndDropped()).
> >
> > So you hide the low-level events within Widget classes, which when they
> receive the event can
> > trigger the collection of ClickListeners / MouseListeners /
> MyFancyListenerNumber3.
> >
> > adding your "double-click" behavior to each
> > one in it's onBrowserEvent method, you're doing it wrong. The correct way
> is to extend once, and
> > allow for adding any additional listeners (double-click, keyboard, etc.)
> to the extended class
> > (which should trigger them in it's onBrowserEvent method). This way the
> event handling logic remains
> > separated from the Widget itself.
> >
> > Also bare in mind Composite style classes (like a TabPanel) that want to
> turn a Click event on a tab
> > into onBeforeTabSelected and onTabSelected for it's TabListeners.
> >
> > Hope that helps a bit.
> >
> > David H. Cook 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

Re: What am I misunderstanding about the event model?

[David H. Cook]

Jason -

You wrote:
"The problem with the standard DOM EventListeners is that only one
listener can be attached to an
Element. The other problem is that a custom Widget may be required to
listen for a sequence of
low-level events in order to trigger a single high-level event (think
MOUSEDOWN/UP/MOVE in relation
to itemDraggedAndDropped())"

Yes!   I agree totatlly! There are nothing BUT problems with the event
model.
So, with those shortcomings, why did they implement it that way?

Like the 'roughian' man said so succinctly:
"You can't addEventListener() to anything I'm aware of."

That's my criticism in a nutshell!  So, why didn't they implement it
that way?
Then they wouldn't have even NEEDED all those other (foolish) Listener-
APIs
with all their shortcomings!

You wrote:
 "If you are extending the classes over and over again..."

NO, I'm NOT!  I don't like it that I need to!  So, I refuse.

In fact, what I found myself doing was to change my whole design (from
what I had when I first implemented it in the old javascript-model) so
that
I am NOT implementing DBL-CLICK,  because of the need to sub-class.

[I found a thread a week ago or so, where someone found that in the
soon-to-be
released GWT 1.60, there was some refactoring of event-stuff, and I am
hoping
against hope that they were ripping out ALL the event-routines, and
simplifying,
but of course, they aren't.  The community would be in an uproar.
(Except for me.!)
I'd welcome it with open-arms, as I have just one small app written in
GWT, and
would be more than happy to re-write all the event-stuff, if they were
to redesign
it totally.]



On Dec 22, 3:04 am, Jason Morris  wrote:
> The GWT event model is a close relation of the standard Java event model.
>
> The problem with the standard DOM EventListeners is that only one listener 
> can be attached to an
> Element. The other problem is that a custom Widget may be required to listen 
> for a sequence of
> low-level events in order to trigger a single high-level event (think 
> MOUSEDOWN/UP/MOVE in relation
> to itemDraggedAndDropped()).
>
> So you hide the low-level events within Widget classes, which when they 
> receive the event can
> trigger the collection of ClickListeners / MouseListeners / 
> MyFancyListenerNumber3.
>
> adding your "double-click" behavior to each
> one in it's onBrowserEvent method, you're doing it wrong. The correct way is 
> to extend once, and
> allow for adding any additional listeners (double-click, keyboard, etc.) to 
> the extended class
> (which should trigger them in it's onBrowserEvent method). This way the event 
> handling logic remains
> separated from the Widget itself.
>
> Also bare in mind Composite style classes (like a TabPanel) that want to turn 
> a Click event on a tab
> into onBeforeTabSelected and onTabSelected for it's TabListeners.
>
> Hope that helps a bit.
>
> David H. Cook 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,
> > 

Re: What am I misunderstanding about the event model?

[Jason Morris]

The GWT event model is a close relation of the standard Java event model.

The problem with the standard DOM EventListeners is that only one listener can 
be attached to an 
Element. The other problem is that a custom Widget may be required to listen 
for a sequence of 
low-level events in order to trigger a single high-level event (think 
MOUSEDOWN/UP/MOVE in relation 
to itemDraggedAndDropped()).

So you hide the low-level events within Widget classes, which when they receive 
the event can 
trigger the collection of ClickListeners / MouseListeners / 
MyFancyListenerNumber3.

If you are extending the classes over and over again, adding your 
"double-click" behavior to each 
one in it's onBrowserEvent method, you're doing it wrong. The correct way is to 
extend once, and 
allow for adding any additional listeners (double-click, keyboard, etc.) to the 
extended class 
(which should trigger them in it's onBrowserEvent method). This way the event 
handling logic remains 
separated from the Widget itself.

Also bare in mind Composite style classes (like a TabPanel) that want to turn a 
Click event on a tab 
into onBeforeTabSelected and onTabSelected for it's TabListeners.

Hope that helps a bit.

David H. Cook 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
-~--~~~~--~~--~--~---