Huh? I don't get what you consider what is wrong with how GWT does
events, other than you don't seem to like the way they look. How is
what you describe any more than a superficial change to achieve the
For what it's worth, GWT event system is something I understood almost
immeaditly without visual aids. I'm confused about what you're trying
to do, even with the visual aids I don't get it.
>From what I understand you take the MVC paradigm into the client -
instead of registering loose ClickListeners etc here and there, you
propose grouping the controller logic into classes - the Controllers -
and sepperating them from the View, the widgets that is. Provided that
one actually also obtains the browser events fired this seems like a
very promising architecture. Very nice thinking!
I am not sure I entirely follow your reasoning on the event handling
stuff, but it sounds like, when implementing your own custom
components, you ran into some limitations and had to extend things to
expose event objects and prevent code duplication in impl classes.
Maybe a more concrete example, or more elaboration, would help people
who have not yet run into the same complications. (For example "e.g.
canceling a "Tab" keypress on a button " - I thought this was already
possible, but maybe I don't understand the example.)
Mat Gessel wrote:
> I'm putting the polish on Tk 1.2. One of the features is a redesign of event
> handling. I wrote up a document explaining the problems I ran into with GWT
> and my approach to solving them:
> So far I've only written a handful of widgets with this design, but I see no
> major problems with the design. Questions and feedback are welcome.
> posted some UML diagrams to help people understand GWT internals.
> You can find out more about GWT Tk here:
> -= Mat
> Mat Gessel
> http://www.asquare.net <http://www.asquare.net/gwt>
> Content-Type: text/html; charset=ISO-8859-1
> X-Google-AttachSize: 1310
> I'm putting the polish on Tk 1.2. One of the features is a redesign of event handling. I wrote up a document explaining the problems I ran into with GWT and my approach to solving them: <br><a href="http://www.asquare.net/gwttk/docs/tk/ControllerDesign.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
> http://www.asquare.net/gwttk/docs/tk/ControllerDesign.html</a><br>So far I've only written a handful of widgets with this design, but I see no major problems with the design. Questions and feedback are welcome. <br><br><a href="http://www.google.com/notebook/fullpage#b=BDSnhIgoQj_Od1c0h" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
> </a>I've also posted some UML diagrams to help people understand GWT internals. <br>
> <a href="http://www.asquare.net/gwt/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.asquare.net/gwt/</a><br><br>You can find out more about GWT Tk here: <br><a href="http://www.asquare.net/gwttk/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
> http://www.asquare.net/gwt/gwttk/</a><br><br>-= Mat<br><br>--
> <br>Mat Gessel<br><a href="http://www.asquare.net/gwt" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.asquare.net</a><br><br>
Well, I respect your Good Job, but i completly agree with Sandy, GWT
event management is very well design and enough opened for adding
custom event management :)
Sure many body here don't know how use sinkEvent and onBrowseEvent()
but again , the GWT documention is very clear and i like it. Maybe you
will help them but ...
I agree with Mat that it might be beneficial to have the event passed
to listeners. I have code that allows rows of a table to be selected.
My selection model supports the control and shift keys. The
TableListener passes the row and cell index but not the event. But I
need the event to determine what keys were pressed at the time of the
event. Because the listener does not get passed the event I had to
abandon the listener approach. I ended overriding the onBrowserEvent
of the FlexTable which has access to the event. This solution works,
but it would have been nice to be able to use the TableListener.
I can see where raw access to the Event object is useful but I think
that isn't so commonly needed to change the way things are handled now.
Since the client code is single threaded it may be worth a RFE so that
GWT provides a DOM.eventGet() method that returns the currently
triggered Event object that can be accessed from anywhere when needed.
1) What is wrong with GWT event handling?
The GWT approach to event handling is clear, simple and flexible. Like
others, I felt right at home when I started working in GWT. This post
is not so much a call for change as a sharing of experience.
Any design it has its trade offs. I suspect the Google designers took
a conservative approach; both to reduce implementation risks and
because it is easier to add functionality to a public API than to
Some pros for the GWT event design:
* GWT listener interfaces are clean
* the listener interfaces are factored well
* it's light-weight; native events are not wrapped (I'm unsure of the
real impact of this, but we are dealing with a relatively low
performance scripting language)
* event support is uniform across platforms
* you have to subclass if you need to access the event object
* you (often) have to subclass/override to modify event handling in a
3rd party widget
* can't handle platform-specific events
* you have to bolt an impl class onto each widget for which you wish
to vary event handling by platform. This is additional code to
maintain and increases script size.
2) the design document doesn't explain x, y and z
I'm not out to evangelize here. I know the document is terse, but I
really would rather be coding than making a book of it. Besides, the
design evolved over a few months and I have forgotten some of the
reasons that brought me to the final design. What I can say is that
the widgets are greatly simplified and I am pleased with the result;
few things make me as happy as reducing LOC. Hopefully others can use
the info to save time analyzing their own designs.
3) no event processing diagram
I'll add it to my TODO list.
4) examples would be helpful
Point taken. I'll have GWT Tk up in a few days and you can see plenty
of examples. Meanwhile here are a few to munch on:
SCENARIO A: adding support for a new platform
GWT Tk includes a GlassPanel widget which covers the entire document
or client area, whichever is greater. The strategy GlassPanel uses to
maintain the appropriate dimensions across resizes depends on the
browser. When possible, the the panel is set to 100% HxW; other
platforms require explicit resizing upon window resize events. Lets
say you want to add Konqueror support. All you have to do is create a
concrete controller class which implements GlassPanelController and
add a deferred binding rule to your Module.gwt.xml file. No
subclassing and no unused code branches or impl class definitions
adding to the script size. Others could benefit from the Konqueror
implementation without having to modify their own GlassPanel-derived
SCENARIO B: adding behavior to 3rd party widgets
You can make a widget draggable and disable text selection in GWT Tk like this:
// do this if SomeWidget instanceof asquare.gwt.tk.client.ui.CWidget
SomeWidget w = new SomeWidget();
w.addController(new DragController(new DragWidgetGesture(w)));
// do this if SomeWidget instanceof com.google.gwt.user.client.ui.Widget
CWrapper wrapped = new CWrapper(new SomeWidget());
wrapped.addController(new DragController(new DragWidgetGesture(w)));
SCENARIO C: removing behavior from 3rd party widgets
Lets say you want to enable text selection in a widget where text
selection has been disabled. It is as simple as this:
CantSelectTextWidget w = new CantSelectTextWidget();
SCENARIO D: closed focus cycle for n widgets in n containers
You might want to do this in a modal dialog. The tabindex attribute
can set focus traversal order, but cannot contain focus. You can
prevent the transfer of focus on the major browsers (minus FF/Mac) by
cancelling the mousedown event. How do you get the event object in an
assortment of widgets/panels? Subclass them all and delegate events?
For Tk widgets you just add the TabFocusController to the widget. For
standard widgets you can add controller support via a wrapper.
VerticalPanel outerPanel = new VerticalPanel();
FocusModel focusModel = new FocusModel();
TabFocusController focusController = (TabFocusController)
// assumption: widgets in panel are not included in the focus cycle
HorizontalPanel foo = new HorizontalPanel();
// add some widgets to foo...
HorizontalPanel bar = new HorizontalPanel();
// add some widgets to bar...
// add the same widgets to the focus model...
Button submit = new Button("Submit");
SCENARIO E: writing a new widget and controller
public class MyWidget extends CWidget
protected List createControllers()
List result = new Vector();
public interface MyWidgetController
public static final MyWidgetController INSTANCE =
public class MyWidgetControllerStandard implements MyWidgetController
public int getEventBits()
public void plugIn(Widget w)
// initialize widget, add listeners, install hooks, focus controls, etc...
public void unplug(Widget w)
// null references, restore focus, etc...
public void doBrowserEvent(Widget w, Event e)
* Process events...
* Note that the Widget is passed.
* One controller may be shared among many views.