Widgets added in constructor fail to send gwt event by HandlerManager
Hi I have two panel. Panel A contains labels with onClick event definition. It will send custom GWT event to Panel B to modify the appearance of Panel B. The event bus is defined on their parent panel, outside of constructor. private HandlerManager eventBus= new HandlerManager(this); The labels and its onClick event definition, created by the constructor of Panel A, fail to send GWT event. I have put the breakpoints on the eventbus handler. No event is received. The labels and their onClick, created by other methods but not the constructor, have sent the gwt events to the eventbus handler. Is there any relationship or the order restriction, e.g the completion of the constructor, on defining the eventbus and using it to send gwt event? Thanks -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Use of HandlerManager in GWT example code conflicts with javadoc
The doc was written before EventBus (or even Places and Activities) was introduced. There's a reason these are articles with a date in the heading ;-) So, follow the javadoc, use EventBus (but there's nothing fundamentally *wrong* using HandlerManager) On Thursday, June 19, 2014 9:19:42 PM UTC+2, Kay Pac wrote: I've been implementing the MVP pattern for my application. The description of MVP on the site and the example code has been very helpful, especially as I lack experience with GUI patterns and many descriptions of MVP and MVC are somewhat abstract. However, I've noticed that the javadoc for HandlerManager says that developers are strongly discouraged from using it for an event dispatch mechanism, which is the opposite of what seems to be suggested in the code (Contacts and Contacts2). Can someone clarify this point for me? I'm wondering why the discrepancy, and if maybe we should update the example code somehow. Kay -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Use of HandlerManager in GWT example code conflicts with javadoc
I've been implementing the MVP pattern for my application. The description of MVP on the site and the example code has been very helpful, especially as I lack experience with GUI patterns and many descriptions of MVP and MVC are somewhat abstract. However, I've noticed that the javadoc for HandlerManager says that developers are strongly discouraged from using it for an event dispatch mechanism, which is the opposite of what seems to be suggested in the code (Contacts and Contacts2). Can someone clarify this point for me? I'm wondering why the discrepancy, and if maybe we should update the example code somehow. Kay -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: HandlerManager for Cells
Thanks guys. The fix worked for me. Cheers, Mohit -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/VWvM4vMkTPkJ. 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: HandlerManager for Cells
In your Cell constructor you have to call super(focus) to let the cell sink focus events and then overwrite onBrowserEvent() to catch them. Alternatively you could use GWT 2.5 which introduces UiBinder for Cells along with event handler support (see: http://googlewebtoolkit.blogspot.de/2012/06/gwt-2.html). -- J. Am Donnerstag, 28. Juni 2012 07:35:04 UTC+2 schrieb Mohit: Hello everybody, I have a requirement in my project to have event handlers to cells. For example, there is a TextInputCell to which I want to attach a handler to focus event. But AbstractCell doesn't provide any HandlerManager functionality to which I can add a handler. Does anybody has suggestions on how to implement this? Shall I extend TextInputCell and add HandlerManager to it? Thanks Mohit -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Dx2Q0-NgsKEJ. 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: HandlerManager for Cells
What I want to do is fire an event from a cell so that some other widget
can listen to it? For example, I have a text input cell in a table to which
I want to attach a focus handler.
Like:
column.getCell().addFocusHandler(new SomeFocusHandler(){
public void onFocus(SomeFocusEvent sfe){
Window.alert(sfe.getValue()); //Alert the cell value
}
});
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/o5I6foFLkI8J.
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: HandlerManager for Cells
You could try table.addCellPreviewHandler(). Basically the handler is called before a cell receives the event in its Cell.onBrowserEvent() method. The PreviewEvent gives you access to the event type, column index and the row value. So you could check for the focus event and the column and then do your stuff with the row value from outside the table. Cells just render strings so event handling is more low level than in widgets. -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/xNSgNcrfhMMJ. 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.
HandlerManager for Cells
Hello everybody, I have a requirement in my project to have event handlers to cells. For example, there is a TextInputCell to which I want to attach a handler to focus event. But AbstractCell doesn't provide any HandlerManager functionality to which I can add a handler. Does anybody has suggestions on how to implement this? Shall I extend TextInputCell and add HandlerManager to it? Thanks Mohit -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/qS4n1cyZBJYJ. 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.
redundant remove call with HandlerManager
I'm getting an exception trying to remove a HandlerManager. Although
it may not be set, I don't understand this exception because I'm
trapping the exception, even testing for a null HandlerManager.
What's wrong? Can't this sort of error be trapped.
The error is in this method:
public static void cancelWindowClosingLogoff() {
try {
if (windowClosingHandler != null)
windowClosingHandler.removeHandler();
}
catch (Exception e) {
; // probably never been set
}
}
The stack trace, up to windowClosingHandler.removeHandler() above is:
Uncaught exception: java.lang.AssertionError: redundant remove call
at
com.google.web.bindery.event.shared.SimpleEventBus.doRemoveNow(SimpleEventBus.java:
217)
at
com.google.web.bindery.event.shared.SimpleEventBus.doRemove(SimpleEventBus.java:
107)
at com.google.gwt.event.shared.HandlerManager
$Bus.doRemove(HandlerManager.java:42)
at com.google.web.bindery.event.shared.SimpleEventBus
$1.removeHandler(SimpleEventBus.java:163)
at
com.google.gwt.event.shared.LegacyHandlerWrapper.removeHandler(LegacyHandlerWrapper.java:
26)
...
I'm running GWT 2.3.
--
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: redundant remove call with HandlerManager
An AssertionError is a Throwable but not an Exception: http://download.oracle.com/javase/6/docs/api/java/lang/AssertionError.html Anyway, you shouldn't catch the exception, you should rather make sure it doesn't happen. For instance, whenever you removeHandler(), you could null the variable, so the next time you won't try to call removeHandler() a second time on the same HandlerRegistration. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/WDdGNktKeXlOZ1FK. 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: redundant remove call with HandlerManager
Doh! Oh yeah. Thanks. On Jun 2, 11:51 am, Thomas Broyer t.bro...@gmail.com wrote: An AssertionError is a Throwable but not an Exception:http://download.oracle.com/javase/6/docs/api/java/lang/AssertionError... Anyway, you shouldn't catch the exception, you should rather make sure it doesn't happen. For instance, whenever you removeHandler(), you could null the variable, so the next time you won't try to call removeHandler() a second time on the same HandlerRegistration. -- 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: Which method of HandlerManager is ClickListenerCollection.fireClick(widget w) similar with ?
Generally, HandlerManager#fireEvent but for DomEvents (such as ClickEvent) you'll have to use DomEvent.fireNativeEventhttp://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/event/dom/client/DomEvent.html#fireNativeEvent(com.google.gwt.dom.client.NativeEvent, com.google.gwt.event.shared.HasHandlers). But well, actually, you shouldn't need this at all. If you use this.addDomHandler(handler, ClickEvent.getType()) to attach your handlers, the widget's default onBrowserEvent will handle the dispatch for you (and addDomHandler automatically calls sinkEvent for you). You shouldn't even need to use HandlerManager, it's an implementation detail of Widget. As the dochttp://code.google.com/webtoolkit/doc/latest/DevGuideUiCustomWidgets.html#newsuggests, have a look at the Button source code (actually, the code you're interested in is in FocusWidgethttp://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/client/ui/FocusWidget.java#120 ). -- 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: Which method of HandlerManager is ClickListenerCollection.fireClick(widget w) similar with ?
It worked well - Thanks for your help so much ^^ But when we use addDomHandler, it return HandlerRegistration to call removeHandler() method to remove handler: Ex: HandlerRegistration clickHandlerRegistration= addDomHandler(handler, ClickEvent.getType()); HandlerRegistration mouseDownHandlerRegistration = addDomHandler(handler, MouseDownEvent.getType()); HandlerRegistration mouseMoveHandlerRegistration = addDomHandler(handler, MouseMoveEvent.getType()); clickHandlerRegistration.removeHandler(); mouseDownHandlerRegistration.removeHandler(); mouseMoveHandlerRegistration.removeHandler(); So Each time we use addDomHandler, we must define a HandlerRegistration for each handler ? On Apr 13, 3:50 pm, Thomas Broyer t.bro...@gmail.com wrote: Generally, HandlerManager#fireEvent but for DomEvents (such as ClickEvent) you'll have to use DomEvent.fireNativeEventhttp://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/googl..., com.google.gwt.event.shared.HasHandlers). But well, actually, you shouldn't need this at all. If you use this.addDomHandler(handler, ClickEvent.getType()) to attach your handlers, the widget's default onBrowserEvent will handle the dispatch for you (and addDomHandler automatically calls sinkEvent for you). You shouldn't even need to use HandlerManager, it's an implementation detail of Widget. As the dochttp://code.google.com/webtoolkit/doc/latest/DevGuideUiCustomWidgetssuggests, have a look at the Button source code (actually, the code you're interested in is in FocusWidgethttp://code.google.com/p/google-web-toolkit/source/browse/trunk/user/... ). -- 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.
Which method of HandlerManager is ClickListenerCollection.fireClick(widget w) similar with ?
In gwt 1.5, I used ClickListenerCollection to manage listeners. But in
gwt 1.6 It has been deprecated, so I used HandlerManager.
public void onBrowserEvent(Event event) {
switch (DOM.eventGetType(event)) {
case Event.ONCLICK:
if(clickListeners != null){
clickListeners.fireClick(this);
}
break;
}
}
ClickListenerCollection = use method: fireClick(Widget w)
HandlerManager = which method is similar with fireClick? fireEvent ?
- And How to use
thanks so much
--
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: HandlerManager is deprecated and theres no removeHandler(...) method at SimpleEventBus class
Thanks for the link. I already had found that though. The threads I could find from that do say that HandlerManager will be undeprecated, but they convey it in a way that implies that they wish it wasn't necessary. I am left with the impression that there is a drive to get rid of HandlerManager, and I'm still left wondering why. Is it the particular implementation that is the problem? Or is there an inherent problem in my design because I think I need it? -- 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: HandlerManager is deprecated and theres no removeHandler(...) method at SimpleEventBus class
Excuse me for coming in late to the whole HandlerManager deprecation
business, but I just found out about it because I upgraded GWT and got
deluged with deprecation warnings, but...
What exactly is the problem with HandlerManager? I've seen some references
in old threads to its complexity. Is that it? Or did that also mean it has
performance issues? Or is there something inherently wrong with the designs
it lends itself to?
For me it seemed to be exactly what I needed. I implemented my event bus so
that it had a set of static methods that delegated to a singleton instance
of HandlerManager. That meant that my classes that implemented an event
handler looked like this:
public class SomeThing implements MyEventHandler{
public SomeThing(){
MyEventBus.addHandler(MyEvent.TYPE,this);
...
}
@Override
protected void finalize() throws Throwable }
MyEventBus.removeHandler(this);
...
}
}
and the classes that fired events just made calls to
MyEventBus.fireEvent(new MyEvent()).
To implement this with SimpleEventBus, I will have to keep my own MapH
extends EventHandler,HandlerRegistration that I will have to manage. So,
it doesn't seem like a big plus to me.
The javadocs on SimpleEventBus suggest a design based on creating handlers
as anonymous inner classes and having the Event class take care the handler
registration (although it still seems to be the handler class that knows how
to find the eventBus). Is there an advantage to doing things this way?
--
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: HandlerManager is deprecated and theres no removeHandler(...) method at SimpleEventBus class
http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/2e4c986ae1bd2c8b/551c19bbff3ed942
On Feb 14, 3:43 pm, malcolm.davis malcolm.da...@bms.com wrote:
Excuse me for coming in late to the whole HandlerManager deprecation
business, but I just found out about it because I upgraded GWT and got
deluged with deprecation warnings, but...
What exactly is the problem with HandlerManager? I've seen some references
in old threads to its complexity. Is that it? Or did that also mean it has
performance issues? Or is there something inherently wrong with the designs
it lends itself to?
For me it seemed to be exactly what I needed. I implemented my event bus so
that it had a set of static methods that delegated to a singleton instance
of HandlerManager. That meant that my classes that implemented an event
handler looked like this:
public class SomeThing implements MyEventHandler{
public SomeThing(){
MyEventBus.addHandler(MyEvent.TYPE,this);
...
}
@Override
protected void finalize() throws Throwable }
MyEventBus.removeHandler(this);
...
}
}
and the classes that fired events just made calls to
MyEventBus.fireEvent(new MyEvent()).
To implement this with SimpleEventBus, I will have to keep my own MapH
extends EventHandler,HandlerRegistration that I will have to manage. So,
it doesn't seem like a big plus to me.
The javadocs on SimpleEventBus suggest a design based on creating handlers
as anonymous inner classes and having the Event class take care the handler
registration (although it still seems to be the handler class that knows how
to find the eventBus). Is there an advantage to doing things this way?
--
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.
HandlerManager is deprecated and theres no removeHandler(...) method at SimpleEventBus class
Hi everybody, This is my scenario. My app is designed using Tabs concepts. Sometimes the Tab 1 wanna be notified about something that happens on Tab 2-N. For that, I have a singleton instance of HandlerManager. Now imagine this: the user closed the tab 1. I think is a good idea keep my HandlerManager clean, so when that happens I use the method removeHandler to remove everything that tab 1 has registered. I upgraded my project to use gwt 2.1. I saw that HandleManager is deprecated and I should use SimpleEventBus. I didnt find the removeHandler(...) method at SimpleEventBus. How do I keep my EventBus clean now? Thanks -- 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-tool...@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: HandlerManager is deprecated and theres no removeHandler(...) method at SimpleEventBus class
Whenever you add an event handler to the SimpleEventBus (or even a widget for that matter), it will return an instance of a HandlerRegistration object. That object has only one purpose - to remove the handler. Just hold onto those objects somewhere, and when your tab gets closed, have them all cleaned up. -Ben On Jan 10, 8:40 am, Mike mikematsum...@gmail.com wrote: Hi everybody, This is my scenario. My app is designed using Tabs concepts. Sometimes the Tab 1 wanna be notified about something that happens on Tab 2-N. For that, I have a singleton instance of HandlerManager. Now imagine this: the user closed the tab 1. I think is a good idea keep my HandlerManager clean, so when that happens I use the method removeHandler to remove everything that tab 1 has registered. I upgraded my project to use gwt 2.1. I saw that HandleManager is deprecated and I should use SimpleEventBus. I didnt find the removeHandler(...) method at SimpleEventBus. How do I keep my EventBus clean now? Thanks -- 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-tool...@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: HandlerManager is deprecated and theres no removeHandler(...) method at SimpleEventBus class
Oh, I didnt saw that. DUH! lol ty man On Jan 10, 12:43 pm, Ben Imp benlee...@gmail.com wrote: Whenever you add an event handler to the SimpleEventBus (or even a widget for that matter), it will return an instance of a HandlerRegistration object. That object has only one purpose - to remove the handler. Just hold onto those objects somewhere, and when your tab gets closed, have them all cleaned up. -Ben On Jan 10, 8:40 am, Mike mikematsum...@gmail.com wrote: Hi everybody, This is my scenario. My app is designed using Tabs concepts. Sometimes the Tab 1 wanna be notified about something that happens on Tab 2-N. For that, I have a singleton instance of HandlerManager. Now imagine this: the user closed the tab 1. I think is a good idea keep my HandlerManager clean, so when that happens I use the method removeHandler to remove everything that tab 1 has registered. I upgraded my project to use gwt 2.1. I saw that HandleManager is deprecated and I should use SimpleEventBus. I didnt find the removeHandler(...) method at SimpleEventBus. How do I keep my EventBus clean now? Thanks -- 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-tool...@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: HandlerManager is deprecated and theres no removeHandler(...) method at SimpleEventBus class
You could also use a ResettableEventBus for each tab and then call its reset() method to remove in one go all handlers registered through this bus. -- 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-tool...@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.
[gwt-contrib] [google-web-toolkit] r9358 committed - Undeprecate HandlerManager and TabPanel, neither of which is quite...
Revision: 9358
Author: gwt.mirror...@gmail.com
Date: Mon Dec 6 07:53:26 2010
Log: Undeprecate HandlerManager and TabPanel, neither of which is quite
ready to die yet.
Review at http://gwt-code-reviews.appspot.com/1187801
Review by: jlaba...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=9358
Modified:
/trunk/user/src/com/google/gwt/event/shared/HandlerManager.java
/trunk/user/src/com/google/gwt/user/client/ui/TabPanel.java
/trunk/user/src/com/google/gwt/user/client/ui/Widget.java
===
--- /trunk/user/src/com/google/gwt/event/shared/HandlerManager.java Tue
Oct 5 11:03:13 2010
+++ /trunk/user/src/com/google/gwt/event/shared/HandlerManager.java Mon
Dec 6 07:53:26 2010
@@ -19,12 +19,16 @@
/**
* Manager responsible for adding handlers to event sources and firing
those
- * handlers on passed in events. Primitive ancestor of {...@link EventBus},
- * and used at the core of {com.google.gwt.user.client.ui.Widget}.
- *
- * @deprecated use {...@link SimpleEventBus}.
+ * handlers on passed in events. Primitive ancestor of {...@link EventBus},
and
+ * used at the core of {com.google.gwt.user.client.ui.Widget}.
+ * p
+ * While widget authors should continue to use
+ * {...@link com.google.gwt.user.client.ui.Widget#addDomHandler(EventHandler,
com.google.gwt.event.dom.client.DomEvent.Type)}
+ * and
+ * {...@link com.google.gwt.user.client.ui.Widget#addHandler(EventHandler,
Type)},
+ * application developers are strongly discouraged from using a
HandlerManager
+ * instance as a global event dispatch mechanism.
*/
-...@deprecated
public class HandlerManager implements HasHandlers {
private final SimpleEventBus eventBus;
@@ -50,6 +54,7 @@
* @param source the event source
* @param fireInReverseOrder true to fire handlers in reverse order
*/
+ @SuppressWarnings(deprecation)
public HandlerManager(Object source, boolean fireInReverseOrder) {
eventBus = new SimpleEventBus(fireInReverseOrder);
this.source = source;
@@ -114,6 +119,7 @@
* @param type the handler's event type
* @return the given handler
*/
+ @SuppressWarnings(deprecation)
public H extends EventHandler H getHandler(GwtEvent.TypeH type, int
index) {
return eventBus.getHandler(type, index);
}
@@ -124,6 +130,7 @@
* @param type the event type
* @return the number of registered handlers
*/
+ @SuppressWarnings(deprecation)
public int getHandlerCount(Type? type) {
return eventBus.getHandlerCount(type);
}
@@ -134,6 +141,7 @@
* @param e the event type
* @return whether the given event type is handled
*/
+ @SuppressWarnings(deprecation)
public boolean isEventHandled(Type? e) {
return eventBus.isEventHandled(e);
}
===
--- /trunk/user/src/com/google/gwt/user/client/ui/TabPanel.java Tue Oct 5
11:03:13 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/TabPanel.java Fri Dec 3
10:28:00 2010
@@ -58,18 +58,13 @@
* h3Example/h3
* {...@example com.google.gwt.examples.TabPanelExample}
* /p
- *
- * @deprecated Use {...@link TabLayoutPanel} instead, but understand that it
is
- * not a drop in replacement for this class. It requires
standards
- * mode, and is most easily used under a {...@link
RootLayoutPanel} (as
- * opposed to a {...@link RootPanel}
*
* @see TabLayoutPanel
*/
// Cannot do anything about tab panel implementing TabListener until next
// release
-...@deprecated
+...@suppresswarnings(deprecation)
public class TabPanel extends Composite implements TabListener,
SourcesTabEvents, HasWidgets, HasAnimation, IndexedPanel.ForIsWidget,
HasBeforeSelectionHandlersInteger, HasSelectionHandlersInteger {
===
--- /trunk/user/src/com/google/gwt/user/client/ui/Widget.java Thu Oct 14
06:34:39 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/Widget.java Fri Dec 3
10:28:00 2010
@@ -55,7 +55,6 @@
*/
int eventsToSink;
private boolean attached;
- @SuppressWarnings(deprecation)
private HandlerManager handlerManager;
private Object layoutData;
private Widget parent;
@@ -74,7 +73,6 @@
* @param handler the handler
* @return {...@link HandlerRegistration} used to remove the handler
*/
- @SuppressWarnings(deprecation)
public final H extends EventHandler HandlerRegistration addDomHandler(
final H handler, DomEvent.TypeH type) {
assert handler != null : handler must not be null;
@@ -91,7 +89,6 @@
* @param handler the handler
* @return {...@link HandlerRegistration} used to remove the handler
*/
- @SuppressWarnings(deprecation)
public final H extends EventHandler HandlerRegistration addHandler(
final H handler, GwtEvent.TypeH type) {
return ensureHandlers().addHandler(type, handler);
@@ -101,7 +98,6 @@
return this;
}
- @SuppressWarnings(deprecation)
public
[gwt-contrib] Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
Reviewers: jlabanca, Description: Undeprecate HandlerManager and TabPanel, neither of which is quite ready to die yet. Please review this at http://gwt-code-reviews.appspot.com/1187801/show Affected files: M user/src/com/google/gwt/event/shared/HandlerManager.java M user/src/com/google/gwt/user/client/ui/TabPanel.java M user/src/com/google/gwt/user/client/ui/Widget.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
John, there have been internal discussions about both of these un-deprecations. Joel wants TabPanel to be blessed again, and we lack any alternative to HandlerManager for widget developers so far. On 2010/12/03 18:47:12, rjrjr wrote: http://gwt-code-reviews.appspot.com/1187801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
http://code.google.com/p/google-web-toolkit/issues/detail?id=5709 http://gwt-code-reviews.appspot.com/1187801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
LGTM Just curious why we need to @SuppressWarnings in HandlerManager http://gwt-code-reviews.appspot.com/1187801/diff/1/2 File user/src/com/google/gwt/event/shared/HandlerManager.java (right): http://gwt-code-reviews.appspot.com/1187801/diff/1/2#newcode57 user/src/com/google/gwt/event/shared/HandlerManager.java:57: @SuppressWarnings(deprecation) Why is the suppresswarning needed? http://gwt-code-reviews.appspot.com/1187801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
Various package private methods on SimpleEventBus exist only for legacy support for HandlerManager, and are deprecated. I don't want new code calling them. On Fri, Dec 3, 2010 at 12:22 PM, jlaba...@google.com wrote: LGTM Just curious why we need to @SuppressWarnings in HandlerManager http://gwt-code-reviews.appspot.com/1187801/diff/1/2 File user/src/com/google/gwt/event/shared/HandlerManager.java (right): http://gwt-code-reviews.appspot.com/1187801/diff/1/2#newcode57 user/src/com/google/gwt/event/shared/HandlerManager.java:57: @SuppressWarnings(deprecation) Why is the suppresswarning needed? http://gwt-code-reviews.appspot.com/1187801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Deprecated HandlerManager and svn 2.1 branch question
On 29 nov, 17:09, Andy pula...@gmail.com wrote: I'm updating my little gwt-traction library and noticed that it's giving compile warnings when I compile with the 2.1 jar downloaded fromhttp://code.google.com/webtoolkit/download.html I often build from source and looking at the 2.1 branch, it doesn't look deprecated: http://code.google.com/p/google-web-toolkit/source/browse/branches/2 This is the pre-I/O branch. GWT 2.1 is in releases/2.1 (and yes, it's misleading!) Question 1: What svn branch should I build to create the equivalent of the released jars? GWT 2.1.0 is in tags/2.1.0 I understand that HandlerManager is being replaced with SimpleEventBus but there was some discussion in September that it's still OK within Widgets. See herehttp://groups.google.com/group/google-web-toolkit/browse_frm/thread/4... Question 2: Should I just suppress warnings or actually change the HandlerManager in the Viewport code below? http://code.google.com/p/gwt-traction/source/browse/src/com/tractions... If HandlerManager works, you can keep it (as it's still used inside Widget, it's still fully functional). I'd however switch to a SimpleEventBus and see what happens (FYI HandlerManager wraps a SimpleEventBus and adds some behavior specific to handling DOM events, and I think also some things for backwards compatibility) -- 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-tool...@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.
Deprecated HandlerManager and svn 2.1 branch question
I'm updating my little gwt-traction library and noticed that it's giving compile warnings when I compile with the 2.1 jar downloaded from http://code.google.com/webtoolkit/download.html I often build from source and looking at the 2.1 branch, it doesn't look deprecated: http://code.google.com/p/google-web-toolkit/source/browse/branches/2.1/user/src/com/google/gwt/event/shared/HandlerManager.java I made the jump from cvs to mercurial and haven't used svn extensively, so maybe there's something about svn that I'm missing, but I assumed that this would be the code for the 2.1 release. Question 1: What svn branch should I build to create the equivalent of the released jars? I understand that HandlerManager is being replaced with SimpleEventBus but there was some discussion in September that it's still OK within Widgets. See here http://groups.google.com/group/google-web-toolkit/browse_frm/thread/4c96f539e1b863fe/a73f6eb3d9f7e2f6 Question 2: Should I just suppress warnings or actually change the HandlerManager in the Viewport code below? http://code.google.com/p/gwt-traction/source/browse/src/com/tractionsoftware/gwt/user/client/Viewport.java Thanks, Andy -- 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-tool...@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: Deprecated HandlerManager and svn 2.1 branch question
HandlerManager has been replaced with EventBus. You could swap it out with new SimpleEventBus(); On Nov 29, 10:09 am, Andy pula...@gmail.com wrote: I'm updating my little gwt-traction library and noticed that it's giving compile warnings when I compile with the 2.1 jar downloaded fromhttp://code.google.com/webtoolkit/download.html I often build from source and looking at the 2.1 branch, it doesn't look deprecated: http://code.google.com/p/google-web-toolkit/source/browse/branches/2 I made the jump from cvs to mercurial and haven't used svn extensively, so maybe there's something about svn that I'm missing, but I assumed that this would be the code for the 2.1 release. Question 1: What svn branch should I build to create the equivalent of the released jars? I understand that HandlerManager is being replaced with SimpleEventBus but there was some discussion in September that it's still OK within Widgets. See herehttp://groups.google.com/group/google-web-toolkit/browse_frm/thread/4... Question 2: Should I just suppress warnings or actually change the HandlerManager in the Viewport code below? http://code.google.com/p/gwt-traction/source/browse/src/com/tractions... Thanks, Andy -- 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-tool...@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: HandlerManager / (Simple)EventBus
- I am having problem X while doing Y ... - Why are you doing Y ? I am guilty of that too, though I think it is so annoying. On Oct 19, 5:30 am, Jeff Larsen larse...@gmail.com wrote: Why do you need to know how many handlers are listening for a specific type of event? On Oct 18, 4:22 pm, dingwa scott@gmail.com wrote: Hi all, I have just upgraded to 2.1.0.RC1 and I have found that the HandlerManager.getHandlerCount() method has been deprecated and made package private. I currently use this method to find out how many handlers are listening for a specific type of event. How am I able to retain this functionality with the 2.1.0.RC1 release? Cheers! -- 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-tool...@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: HandlerManager / (Simple)EventBus
On 19 oct, 10:22, dmen dmenou...@gmail.com wrote: - I am having problem X while doing Y ... - Why are you doing Y ? I am guilty of that too, though I think it is so annoying. By understanding the why of Y, you can try to find another way of answering the why without doing Y, so that you don't face problem X. -- 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-tool...@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: HandlerManager / (Simple)EventBus
So maybe I'm embracing (/ misusing) the HandlerManager a bit too much here. But I am trying to show the login progress (via a progressBar) in my app. I have a LoginAppController that fires off a LoginEvent for which various AppControllers are listening for. When each of these AppControllers receive the LoginEvent they then perform what they have to do to login their part of the application. Once each AppController finishes their respective login function, a LoggedOnEvent is fired back into the HandlerManager for which my LoginAppController is listening for. And as you can see, if I can get number of AppControllers listening for the LoginEvent, I am able to work out exactly my progress of the login routine as the LoginAppController receives the LoggedOnEvents. Now with this out of the way, how could I now potentially do this in 2.1.0.RC1? thanks On Oct 19, 10:26 am, Thomas Broyer t.bro...@gmail.com wrote: On 19 oct, 10:22, dmen dmenou...@gmail.com wrote: - I am having problem X while doing Y ... - Why are you doing Y ? I am guilty of that too, though I think it is so annoying. By understanding the why of Y, you can try to find another way of answering the why without doing Y, so that you don't face problem X. -- 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-tool...@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.
[gwt-contrib] Re: HandlerManager is going way of the dodo!
I am glad my comment entertained ya :) On Oct 18, 8:17 pm, Stephen Haberman stephen.haber...@gmail.com wrote: (re: dmen, I enjoyed your message. :-) - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
HandlerManager / (Simple)EventBus
Hi all, I have just upgraded to 2.1.0.RC1 and I have found that the HandlerManager.getHandlerCount() method has been deprecated and made package private. I currently use this method to find out how many handlers are listening for a specific type of event. How am I able to retain this functionality with the 2.1.0.RC1 release? Cheers! -- 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-tool...@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: HandlerManager / (Simple)EventBus
Why do you need to know how many handlers are listening for a specific type of event? On Oct 18, 4:22 pm, dingwa scott@gmail.com wrote: Hi all, I have just upgraded to 2.1.0.RC1 and I have found that the HandlerManager.getHandlerCount() method has been deprecated and made package private. I currently use this method to find out how many handlers are listening for a specific type of event. How am I able to retain this functionality with the 2.1.0.RC1 release? Cheers! -- 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-tool...@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.
[gwt-contrib] HandlerManager is going way of the dodo!
I love how you deprecate core stuff, just like that. It shows how much thought you put before introducing APIs. By now, it seems like half of GWT API must be at deprecated state. No problem, simply slap @Deprecated, @SuppressWarnings(deprecation) all over the place and you 're done. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] HandlerManager is going way of the dodo!
In the case of HandlerManager, you just need to replace it with EventBus/SimpleEventBus. The interface is nice if you're working with gin and it's also nice for unit testing. If you don't want to be bothered too much, just substitute all instances of HandlerManager with SimpleEventBus and you're done. On Sun, Oct 17, 2010 at 1:47 PM, dmen dmenou...@gmail.com wrote: I love how you deprecate core stuff, just like that. It shows how much thought you put before introducing APIs. By now, it seems like half of GWT API must be at deprecated state. No problem, simply slap @Deprecated, @SuppressWarnings(deprecation) all over the place and you 're done. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] HandlerManager is going way of the dodo!
If you don't want to be bothered too much, just substitute all instances of HandlerManager with SimpleEventBus and you're done. I dunno--per my comment in a proposed patch to SimpleEventBus, I find using EventBus in all the places I used HandlerManager to be odd. I used HandlerManager inside of objects to handle object-specific events (much like it's used in Widget for Widget-specific events). To me, this usage isn't an event bus...event bus == app-wide stuff. Having an app-wide EventBus field inside of a Widget (or Property or whatever) leads to confusion: this is /the/ app-wide event bus, or just /a/ object-specific event bus. IMO, keeping the two classes separate makes more sense to me. The satisfy two separate roles in an app. That their internals are fairly similar is an implementation detail. (re: dmen, I enjoyed your message. :-) - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] HandlerManager is going way of the dodo!
I think you're getting hung up on the name, Stephen. The only differences between the two classes is that the move to EventBus gave us a chance to simplify the api. They do they same thing, and for the most part an EventBus is a drop in replacement for a HandlerManager. HandlerManager was written before the notion of app wide events had taken hold, and would have been a simpler beast had that been true. As a team and a community, we backed into using HM for that purpose. Re: our habit of not cleaning up after our deprecations, guilty as charged. I'm hoping we can get on top of that soon. On Mon, Oct 18, 2010 at 10:17 AM, Stephen Haberman stephen.haber...@gmail.com wrote: If you don't want to be bothered too much, just substitute all instances of HandlerManager with SimpleEventBus and you're done. I dunno--per my comment in a proposed patch to SimpleEventBus, I find using EventBus in all the places I used HandlerManager to be odd. I used HandlerManager inside of objects to handle object-specific events (much like it's used in Widget for Widget-specific events). To me, this usage isn't an event bus...event bus == app-wide stuff. Having an app-wide EventBus field inside of a Widget (or Property or whatever) leads to confusion: this is /the/ app-wide event bus, or just /a/ object-specific event bus. IMO, keeping the two classes separate makes more sense to me. The satisfy two separate roles in an app. That their internals are fairly similar is an implementation detail. (re: dmen, I enjoyed your message. :-) - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] HandlerManager is going way of the dodo!
I think you're getting hung up on the name, Stephen. Yeah, I know. :-) I'll get used to the name, I can just foresee explaining no, this event bus here in Widget isn't /the/ event bus as a idiosyncrasy to fellow team members/GWT newbies. HandlerManager was written before the notion of app wide events had taken hold, and would have been a simpler beast had that been true. As a team and a community, we backed into using HM for that purpose. Agreed. I'm glad there is an explicit EventBus now. I deleted my own EventBus interface last week in favor of the canonical one. As you say, HM was for a different purpose. Also, apologies for only piping up when I have negative things to say. All things considered, I love the progress GWT is making. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] HandlerManager/SimpleEventBus doesn't need to defer adds
A patch for SimpleEventBus would be great. I'm more reluctant to mess with HandlerManager, which is deprecated in 2.1. Cool! I hadn't noticed that HandlerManager was deprecated. Hopefully I did this right: http://gwt-code-reviews.appspot.com/979801/show Thanks, Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] HandlerManager/SimpleEventBus doesn't need to defer adds
A patch for SimpleEventBus would be great. I'm more reluctant to mess with HandlerManager, which is deprecated in 2.1. On Fri, Oct 8, 2010 at 2:35 PM, Stephen Haberman step...@exigencecorp.comwrote: Hi, In both HandlerManager and SimpleEventBus, both adds and removes are buffered while events are firing. However, adds to not need to be deferred. Especially since the firing lock is eventbus wide, I have gotten bit by this where in one event handler (say, presenter start), I added an event handler for an unrelated event, briefly later fired it, and did not see my new handler get called. Granted, it is a special case, but it caused me a lot of frustration. As a newbie it seemed like something that should just work. Since then I've been using a hacked HandlerManager that always allows adds to be appended to handler lists. HandlerManager has the easiest fix--just don't cache the handler count while iterating. (And even this is optional, if count was cached, but adds still done directly, then my original scenario of adding a handler for an as-yet-unfired event would be fine.) SimpleEventBus would have to remove its iterators (I assume, otherwise they'd get a concurrent modification exception), and just use a counter based loop as well. Only removes really have to be deferred, because they would shift the handler list out from under any potential iterations. But appends are okay. I'd gladly file a bug and provide patches if given the nod. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: EventBus and HandlerManager Classes. Difference?
Thanks very much, Thomas. This make a little more sense. I keep looking at the base roo application and it is showing ( I think as of M3 with the ScaffoldFactory) the use of the HandlerManager. So it is good to hear that for certain that we are moving away from HandlerManager and to implementations of the EventBus. Thanks very much! On Sep 17, 4:12 pm, Thomas Broyer t.bro...@gmail.com wrote: On Sep 17, 9:05 pm, Ashton Thomas ash...@acrinta.com wrote: I am confused as to when use the abstract class EventBus class that implements HasHandlers:http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/... and the class HandlerManager that also implements HasHandlers:http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/... I know we have th SimpleEventBus that extends EventBus but I am still a bit confused. Can anyone do a brain dumb or drop some info? Basically, HandlerManager is only to be used within widgets (and it is an internal part of Widget, backing the addHandler and addDomHandler methods; so you shouldn't have to use it directly, probably the reason it's marked @Deprecated). If you need an event bus to make you apps components communicate with each others, then you should use EventBus, which SimpleEventBus is an implementation. -- 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-tool...@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: EventBus and HandlerManager Classes. Difference?
On Sep 18, 3:26 pm, Ashton Thomas ash...@acrinta.com wrote: Thanks very much, Thomas. This make a little more sense. I keep looking at the base roo application and it is showing ( I think as of M3 with the ScaffoldFactory) the use of the HandlerManager. SimpleEventBus didn't yet existed in 2.1M3 and HandlerManager was the only (provided) implementation of EventBus. So it is good to hear that for certain that we are moving away from HandlerManager and to implementations of the EventBus. http://code.google.com/p/google-web-toolkit/source/detail?r=8756 Refactors HandlerManager.HandlerRegistry into a new public class, SimpleEventBus. MultiFire, default source stamping, and event recycling are left as features of HandlerManager. HandlerManager no longer implements EventBus interface, in the interest of less confusing API for EventBus users. -- 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-tool...@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: EventBus and HandlerManager Classes. Difference?
Thanks, I was looking for this info before posting. But I have been away from the gwt world for a bit and got out of sync. Thanks! On Sep 18, 7:21 pm, Thomas Broyer t.bro...@gmail.com wrote: On Sep 18, 3:26 pm, Ashton Thomas ash...@acrinta.com wrote: Thanks very much, Thomas. This make a little more sense. I keep looking at the base roo application and it is showing ( I think as of M3 with the ScaffoldFactory) the use of the HandlerManager. SimpleEventBus didn't yet existed in 2.1M3 and HandlerManager was the only (provided) implementation of EventBus. So it is good to hear that for certain that we are moving away from HandlerManager and to implementations of the EventBus. http://code.google.com/p/google-web-toolkit/source/detail?r=8756 Refactors HandlerManager.HandlerRegistry into a new public class, SimpleEventBus. MultiFire, default source stamping, and event recycling are left as features of HandlerManager. HandlerManager no longer implements EventBus interface, in the interest of less confusing API for EventBus users. -- 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-tool...@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.
EventBus and HandlerManager Classes. Difference?
I am confused as to when use the abstract class EventBus class that implements HasHandlers: http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/event/shared/EventBus.java and the class HandlerManager that also implements HasHandlers: http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/event/shared/HandlerManager.java I know we have th SimpleEventBus that extends EventBus but I am still a bit confused. Can anyone do a brain dumb or drop some info? -- 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-tool...@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: EventBus and HandlerManager Classes. Difference?
On Sep 17, 9:05 pm, Ashton Thomas ash...@acrinta.com wrote: I am confused as to when use the abstract class EventBus class that implements HasHandlers:http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/... and the class HandlerManager that also implements HasHandlers:http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/... I know we have th SimpleEventBus that extends EventBus but I am still a bit confused. Can anyone do a brain dumb or drop some info? Basically, HandlerManager is only to be used within widgets (and it is an internal part of Widget, backing the addHandler and addDomHandler methods; so you shouldn't have to use it directly, probably the reason it's marked @Deprecated). If you need an event bus to make you apps components communicate with each others, then you should use EventBus, which SimpleEventBus is an implementation. -- 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-tool...@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.
[gwt-contrib] [google-web-toolkit] r8757 committed - Makes HandlerManager implement HasHandlers again.
Revision: 8757
Author: gwt.mirror...@gmail.com
Date: Sat Sep 11 13:03:13 2010
Log: Makes HandlerManager implement HasHandlers again.
http://code.google.com/p/google-web-toolkit/source/detail?r=8757
Modified:
/trunk/user/src/com/google/gwt/event/shared/HandlerManager.java
===
--- /trunk/user/src/com/google/gwt/event/shared/HandlerManager.java Fri Sep
10 17:56:09 2010
+++ /trunk/user/src/com/google/gwt/event/shared/HandlerManager.java Sat Sep
11 13:03:13 2010
@@ -25,7 +25,7 @@
* @deprecated use {...@link SimpleEventBus}.
*/
@Deprecated
-public class HandlerManager {
+public class HandlerManager implements HasHandlers {
private SimpleEventBus eventBus;
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: How to add new event to HandlerManager
Looks like you're getting the wrong type from KeyPressEvent. Javadoc
says:
getAssociatedType()
Returns the type used to register this event.
getType()
Gets the event type associated with key press events.
for registering, you should use getAssociatedType(), so try
eventBus.addHandler(KeyPressEvent.getAssociatedType(),
On May 31, 1:54 pm, justint too_jus...@hotmail.com wrote:
Hi, I'm fairly new to GWT and I'm trying to add events to my
eventBus...
final HandlerManager eventBus = new HandlerManager(null);
..
eventBus.addHandler(RequestEvent.TYPE, new
RequestEvent.Handler() {
public void onRequestEvent(RequestEvent requestEvent)
{
if (requestEvent.getState() == State.SENT) {
System.out.println(RPC sent!);
}
}
});
This RequestEvent event works fine, but this doesn't work for
instance...or at least I don't think it works:
eventBus.addHandler(KeyPressEvent.getType(), new
KeyPressHandler()
{
public void onKeyPress(KeyPressEvent arg0) {
System.out.println(Key pressed event!);
}
});
Any tips are greatly appreciated!
--
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-tool...@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: How to add new event to HandlerManager
On 31 mai, 20:54, justint too_jus...@hotmail.com wrote:
Hi, I'm fairly new to GWT and I'm trying to add events to my
eventBus...
final HandlerManager eventBus = new HandlerManager(null);
..
eventBus.addHandler(RequestEvent.TYPE, new
RequestEvent.Handler() {
public void onRequestEvent(RequestEvent requestEvent)
{
if (requestEvent.getState() == State.SENT) {
System.out.println(RPC sent!);
}
}
});
This RequestEvent event works fine, but this doesn't work for
instance...or at least I don't think it works:
eventBus.addHandler(KeyPressEvent.getType(), new
KeyPressHandler()
{
public void onKeyPress(KeyPressEvent arg0) {
System.out.println(Key pressed event!);
}
});
Any tips are greatly appreciated!
Are you *really* firing KeyPressEvents on your event bus ?!
@Tristan: getAssociatedType and getType return the same object,
getAssociatedType is not static though, it's part of the GwtEvent
interface (and used by the HandlerManager to find back corresponding
handlers in its internal registry).
--
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-tool...@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: How to add new event to HandlerManager
@Thomas haha... wow... now looking at it in the morning i see what you're
pointing out. I didn't even realize it was KeyPressEvent :)
On Thu, Jun 3, 2010 at 09:39, Thomas Broyer t.bro...@gmail.com wrote:
On 31 mai, 20:54, justint too_jus...@hotmail.com wrote:
Hi, I'm fairly new to GWT and I'm trying to add events to my
eventBus...
final HandlerManager eventBus = new HandlerManager(null);
..
eventBus.addHandler(RequestEvent.TYPE, new
RequestEvent.Handler() {
public void onRequestEvent(RequestEvent
requestEvent) {
if (requestEvent.getState() ==
State.SENT) {
System.out.println(RPC sent!);
}
}
});
This RequestEvent event works fine, but this doesn't work for
instance...or at least I don't think it works:
eventBus.addHandler(KeyPressEvent.getType(), new
KeyPressHandler()
{
public void onKeyPress(KeyPressEvent arg0) {
System.out.println(Key pressed event!);
}
});
Any tips are greatly appreciated!
Are you *really* firing KeyPressEvents on your event bus ?!
@Tristan: getAssociatedType and getType return the same object,
getAssociatedType is not static though, it's part of the GwtEvent
interface (and used by the HandlerManager to find back corresponding
handlers in its internal registry).
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
--
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-tool...@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.
How to add new event to HandlerManager
Hi, I'm fairly new to GWT and I'm trying to add events to my
eventBus...
final HandlerManager eventBus = new HandlerManager(null);
..
eventBus.addHandler(RequestEvent.TYPE, new
RequestEvent.Handler() {
public void onRequestEvent(RequestEvent requestEvent) {
if (requestEvent.getState() == State.SENT) {
System.out.println(RPC sent!);
}
}
});
This RequestEvent event works fine, but this doesn't work for
instance...or at least I don't think it works:
eventBus.addHandler(KeyPressEvent.getType(), new
KeyPressHandler()
{
public void onKeyPress(KeyPressEvent arg0) {
System.out.println(Key pressed event!);
}
});
Any tips are greatly appreciated!
--
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-tool...@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.
Why HandlerManager use quene to register event handler?
Hi, I am new to gwt also this event-handle programing model. I am
trying to use gwt-presenter 1.1.1. However, I have a few problems
with the eventbus. The eventbus in gwt-presenter is actually realized
by HandlerManager. I have a event (EventPage) firing for a page,
within the handling, it calls method B. Within metod B, it makes an
AJAX call for some data, I realize it by calling C function, which
fire another event (EventData) when it receive the data. Here is the
idea
eventbus.addHandler(EventPage.Type, new PageHandler(){
.
B();
}
eventbus.fire(new EventPage())
..
B(){
eventbus.addHandler(EventData.Type, new DataHandler(){
public void processData(EventData event){
...populate page with the data and show it.
});
C();
}
--
C(){
Ajax_call(new callback(){
...
public void onResponseReceived(Request request,
Response response) {
process data,
eventbus.fire(new EventData())
}
My eventbus is an singleton in type of HandlerManager. The problem is
the definition of B() is only accessible after fire EventPage. In the
HandlerManager, there is one variable called firingDepth, it is 0 when
EventPage fires and 1 after. When it is larger than 0, it always
quene the handler registration (addHandler(EventData)) and do not
register until back to firingDepth==0. So when C() fires EventData(),
nothing happens because the handler has not registered yet (it will
not be until C() exits.)
What is the reason to put such a queue into HandlerManager? Is there
anyway to get my problem fixed? Thank you very much.
--
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-tool...@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: Why HandlerManager use quene to register event handler?
On Mar 19, 10:57 pm, zggame zgg...@gmail.com wrote:
Hi, I am new to gwt also this event-handle programing model. I am
trying to use gwt-presenter 1.1.1. However, I have a few problems
with the eventbus. The eventbus in gwt-presenter is actually realized
by HandlerManager. I have a event (EventPage) firing for a page,
within the handling, it calls method B. Within metod B, it makes an
AJAX call for some data, I realize it by calling C function, which
fire another event (EventData) when it receive the data. Here is the
idea
eventbus.addHandler(EventPage.Type, new PageHandler(){
.
B();}
---
-
eventbus.fire(new EventPage())
---
-
..
B(){
eventbus.addHandler(EventData.Type, new DataHandler(){
public void processData(EventData event){
...populate page with the data and show it.
});
C();
}
--
C(){
Ajax_call(new callback(){
...
public void onResponseReceived(Request request,
Response response) {
process data,
eventbus.fire(new EventData())
}
My eventbus is an singleton in type of HandlerManager. The problem is
the definition of B() is only accessible after fire EventPage. In the
HandlerManager, there is one variable called firingDepth, it is 0 when
EventPage fires and 1 after. When it is larger than 0, it always
quene the handler registration (addHandler(EventData)) and do not
register until back to firingDepth==0. So when C() fires EventData(),
nothing happens because the handler has not registered yet (it will
not be until C() exits.)
What is the reason to put such a queue into HandlerManager?
That's because (at firingDepth=0) the code is iterating on the
handlers, so any modification would cause a
ConcurrentModificationException.
Is there
anyway to get my problem fixed? Thank you very much.
Try deferring some of the processing (e.g. Scheduler#scheduleDeferred
or Scheduler#scheduleFinally) so it happens after the events have all
been processed; and more generally treat your event bus as if it were
asynchronous: don't expect handlers to be called back in the same
event pump as the one that fires events.
--
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-tool...@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: Why HandlerManager use quene to register event handler?
Thank you very much. I put a 500ms delay and it works very well now.
These Asyc and event/handler model are really different from what I
was used to on the server-side. Thanks for all the help.
On Mar 19, 5:22 pm, Thomas Broyer t.bro...@gmail.com wrote:
On Mar 19, 10:57 pm, zggame zgg...@gmail.com wrote:
Hi, I am new to gwt also this event-handle programing model. I am
trying to use gwt-presenter 1.1.1. However, I have a few problems
with the eventbus. The eventbus in gwt-presenter is actually realized
by HandlerManager. I have a event (EventPage) firing for a page,
within the handling, it calls method B. Within metod B, it makes an
AJAX call for some data, I realize it by calling C function, which
fire another event (EventData) when it receive the data. Here is the
idea
eventbus.addHandler(EventPage.Type, new PageHandler(){
.
B();}
---
-
eventbus.fire(new EventPage())
---
-
..
B(){
eventbus.addHandler(EventData.Type, new DataHandler(){
public void processData(EventData event){
...populate page with the data and show it.
});
C();
}
--
C(){
Ajax_call(new callback(){
...
public void onResponseReceived(Request request,
Response response) {
process data,
eventbus.fire(new EventData())
}
My eventbus is an singleton in type of HandlerManager. The problem is
the definition of B() is only accessible after fire EventPage. In the
HandlerManager, there is one variable called firingDepth, it is 0 when
EventPage fires and 1 after. When it is larger than 0, it always
quene the handler registration (addHandler(EventData)) and do not
register until back to firingDepth==0. So when C() fires EventData(),
nothing happens because the handler has not registered yet (it will
not be until C() exits.)
What is the reason to put such a queue into HandlerManager?
That's because (at firingDepth=0) the code is iterating on the
handlers, so any modification would cause a
ConcurrentModificationException.
Is there
anyway to get my problem fixed? Thank you very much.
Try deferring some of the processing (e.g. Scheduler#scheduleDeferred
or Scheduler#scheduleFinally) so it happens after the events have all
been processed; and more generally treat your event bus as if it were
asynchronous: don't expect handlers to be called back in the same
event pump as the one that fires events.
--
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-tool...@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: HandlerManager
发自我的 iPod 在 2010-1-22，17:18，DaveC david.andrew.chap...@googlemail.com 写到： Just so I know we're talking about the same thing :o) An Blur event will fire when I either tab out of the Widget or when I click somewhere else in the application - is this how you are trying to cause the blur event to fire? (I had the above code working for me in Firefox 3.0/Dev mode GWT 2 - what browser(s) are you viewing this in?) On Jan 21, 6:24 pm, PaulBee pauloabe...@gmail.com wrote: Thank you DaveC, But the BlurHandler doesn't seem to work on the FocusPanel. I've tryed every way of taking the focus away from the panel, and it is just not calling the BLurHandler... -- 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 . -- 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-tool...@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.
[gwt-contrib] [google-web-toolkit] r7589 committed - Add the ability to change the default HandlerManager of a Widget....
Revision: 7589
Author: jlaba...@google.com
Date: Tue Feb 16 07:48:56 2010
Log: Add the ability to change the default HandlerManager of a Widget.
http://gwt-code-reviews.appspot.com/138801
Patch by: sven.brunken
Review by: jlabanca
http://code.google.com/p/google-web-toolkit/source/detail?r=7589
Modified:
/trunk/user/src/com/google/gwt/user/client/ui/Widget.java
/trunk/user/test/com/google/gwt/user/client/ui/WidgetTest.java
===
--- /trunk/user/src/com/google/gwt/user/client/ui/Widget.java Wed Sep 23
10:15:52 2009
+++ /trunk/user/src/com/google/gwt/user/client/ui/Widget.java Tue Feb 16
07:48:56 2010
@@ -43,9 +43,9 @@
*/
int eventsToSink;
private boolean attached;
+ private HandlerManager handlerManager;
private Object layoutData;
private Widget parent;
- private HandlerManager handlerManager;
public void fireEvent(GwtEvent? event) {
if (handlerManager != null) {
@@ -197,6 +197,16 @@
final H handler, GwtEvent.TypeH type) {
return ensureHandlers().addHandler(type, handler);
}
+
+ /**
+ * Creates the {...@link HandlerManager} used by this Widget. You can
overwrite
+ * this method to create a custom {...@link HandlerManager}.
+ *
+ * @return the {...@link HandlerManager} you want to use
+ */
+ protected HandlerManager createHandlerManager() {
+return new HandlerManager(this);
+ }
/**
* Fires an event on a child widget. Used to delegate the handling of an
event
@@ -359,7 +369,7 @@
* @return the handler manager
* */
HandlerManager ensureHandlers() {
-return handlerManager == null ? handlerManager = new
HandlerManager(this)
+return handlerManager == null ? handlerManager = createHandlerManager()
: handlerManager;
}
===
--- /trunk/user/test/com/google/gwt/user/client/ui/WidgetTest.java Wed Oct
28 09:10:53 2009
+++ /trunk/user/test/com/google/gwt/user/client/ui/WidgetTest.java Tue Feb
16 07:48:56 2010
@@ -18,6 +18,7 @@
import com.google.gwt.event.dom.client.ChangeEvent;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
+import com.google.gwt.event.shared.HandlerManager;
import com.google.gwt.event.shared.HandlerRegistration;
import com.google.gwt.junit.client.GWTTestCase;
@@ -43,6 +44,18 @@
public String getModuleName() {
return com.google.gwt.user.User;
}
+
+ public void testCreateHandlerManager() {
+final HandlerManager manager = new HandlerManager(null);
+Widget w = new Widget() {
+ @Override
+ protected HandlerManager createHandlerManager() {
+return manager;
+ }
+};
+w.ensureHandlers();
+assertEquals(manager, w.getHandlerManager());
+ }
public void testHandlerCount() {
Widget a = new Widget();
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Thinking outload... What about allowing ctors to take a HM. The other ctors use the default implementation. If you dont care for a HM then use the ctors without HM in the parameter list. That way The problem with this is that you then have to add HM to the ctor for every extension of Widget (which are many). you dont pollute the widget method list with gets/creates and sets Well, I think the current consensus is that gets and sets won't happen/aren't necessary for the use case in question. As far as polluting the Widget method list with createHM()... It is a protected method with a default implementation, so 1) You would have to extend Widget (or one of widget's subclasses) to see it. 2) You probably wouldn't see it unless you were purposefully looking for things to extend about Widget which prolly dont make sense once the thing is built. Since the HandlerManager is lazy loading (with good reason, too) the only way this sort of flexible API makes sense is to (1) provide a factory method or (2) allow for a HMFactory in the constructor. I tend towards the factory method because it is a less complex change and because of the problems with constructor extensions mentioned above. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Updated the patch to only add a createHandlerManager which gets called
by ensureHandlers.
On 12 Feb., 04:22, John LaBanca jlaba...@google.com wrote:
Alright, lets go with createHandlerManager() for now. Thanks for all the
feedback.
@sven -
Would you like to update the patch by reverting the getHandlerManager()
method back to a package protected method? If you don't get to it for a few
days, I'll can do it for you.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, Feb 11, 2010 at 9:39 PM, Nathan Wells nwwe...@gmail.com wrote:
I'd say that if you wanted to implement a HandlerManager stack, it
would probably be best to do that internal to the HandlerManager,
rather than forcing a Widget to know how events are handled.
Assuming that is possible given the current Widget implementations
(others more expert than I would know this, probably), the only API I
would want is createHandlerManager(). I could then manage how that
more complex HandlerManager is dealt with.
While we're on the subject... if you're providing this factory method,
I would rather see a well-documented interface to implement rather
than a semi-documented implementation of which I would probably be
overriding every method.
just my .02
On Feb 11, 11:05 am, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7561 committed - Makes HandlerManager execute all event handlers even if one throws an...
Revision: 7561
Author: phopk...@google.com
Date: Thu Feb 11 10:21:52 2010
Log: Makes HandlerManager execute all event handlers even if one throws an
exception. Wraps thrown exceptions in an UmbrellaException (which is
factored out of AttachDetachException).
http://gwt-code-reviews.appspot.com/136805
http://code.google.com/p/google-web-toolkit/source/detail?r=7561
Added:
/trunk/user/src/com/google/gwt/event/shared/UmbrellaException.java
Modified:
/trunk/user/src/com/google/gwt/event/shared/HandlerManager.java
/trunk/user/src/com/google/gwt/user/client/ui/AttachDetachException.java
/trunk/user/test/com/google/gwt/event/shared/HandlerManagerTest.java
===
--- /dev/null
+++ /trunk/user/src/com/google/gwt/event/shared/UmbrellaException.java Thu
Feb 11 10:21:52 2010
@@ -0,0 +1,49 @@
+/*
+ * Copyright 2010 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+package com.google.gwt.event.shared;
+
+import java.util.Set;
+
+/**
+ * A {...@link RuntimeException} that collects a {...@link Set} of child
+ * {...@link Throwable}s together. Typically thrown after loop, with all of
the
+ * exceptions thrown during that loop, but delayed so that the loop
finishes
+ * executing.
+ */
+public class UmbrellaException extends RuntimeException {
+
+ /**
+ * The causes of the exception.
+ */
+ private SetThrowable causes;
+
+ public UmbrellaException(SetThrowable causes) {
+super(
+One or more exceptions caught, see full set in
UmbrellaException#getCauses,
+causes.size() == 0 ? null : causes.toArray(new Throwable[0])[0]);
+this.causes = causes;
+ }
+
+ /**
+ * Get the set of exceptions that caused the failure.
+ *
+ * @return the set of causes
+ */
+ public SetThrowable getCauses() {
+return causes;
+ }
+
+}
===
--- /trunk/user/src/com/google/gwt/event/shared/HandlerManager.java Mon
Nov 2 09:21:49 2009
+++ /trunk/user/src/com/google/gwt/event/shared/HandlerManager.java Thu Feb
11 10:21:52 2010
@@ -19,8 +19,10 @@
import java.util.ArrayList;
import java.util.HashMap;
+import java.util.HashSet;
import java.util.List;
import java.util.Map;
+import java.util.Set;
/**
* Manager responsible for adding handlers to event sources and firing
those
@@ -54,17 +56,39 @@
boolean isReverseOrder) {
TypeH type = event.getAssociatedType();
int count = getHandlerCount(type);
+ SetThrowable causes = null;
+
if (isReverseOrder) {
for (int i = count - 1; i = 0; i--) {
H handler = this.H getHandler(type, i);
- event.dispatch(handler);
+ try {
+event.dispatch(handler);
+ } catch (Throwable e) {
+if (causes == null) {
+ // create lazily to avoid excess creation in general case
+ causes = new HashSetThrowable();
+}
+causes.add(e);
+ }
}
} else {
for (int i = 0; i count; i++) {
H handler = this.H getHandler(type, i);
- event.dispatch(handler);
+ try {
+event.dispatch(handler);
+ } catch (Throwable e) {
+if (causes == null) {
+ // create lazily to avoid excess creation in general case
+ causes = new HashSetThrowable();
+}
+causes.add(e);
+ }
}
}
+
+ if (causes != null) {
+throw new UmbrellaException(causes);
+ }
}
@SuppressWarnings(unchecked)
@@ -162,6 +186,11 @@
* Note, any subclass should be very careful about overriding this
method, as
* adds/removes of handlers will not be safe except within this
* implementation.
+ *
+ * Any exceptions thrown by handlers will be bundled into a
+ * {...@link UmbrellaException} and then re-thrown after all handlers have
+ * completed. An exception thrown by a handler will not prevent other
handlers
+ * from executing.
*
* @param event the event
*/
@@ -175,6 +204,7 @@
try {
firingDepth++;
+ // May throw an UmbrellaException.
registry.fireEvent(event, isReverseOrder);
} finally {
@@ -182,13 +212,14 @@
if (firingDepth == 0) {
handleQueuedAddsAndRemoves();
}
-}
-if (oldSource == null) {
- // This was my event, so I should kill it now that I'm done.
- event.kill();
-} else
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
But what if you have the case where you're setting the HandlerManager specifically because you want to stop listening to all the events from the previous HandlerManager. The idea of a stack of HandlerManagers makes some sense if you want to have different HandlerManagers handling events for different parts of a system. I understand the idea of making your own HandlerManager, but from a design perspective, doesn't it make sense to just have a singleton HandlerManager? Are there performance implications of having everything go through one HandlerManager? All the best, -- Arthur Kalmenson On Wed, Feb 10, 2010 at 11:34 AM, Isaac Truett itru...@gmail.com wrote: The argument seems to revolve around changing HandlerManagers resulting in the loss of registered handlers. Is it possible that the HandlerManager and the set of registered handlers aren't really the same thing and need to be separated? Would everyone be happy if you could call setHandlerManager() and the new manager would still service the same set of handlers that existed previously? On Wed, Feb 10, 2010 at 10:59 AM, Ray Ryan rj...@google.com wrote: I forgot about that nuance of your proposal. I like. @jat: the stack idea is nifty, but expanding the scope of the patch even worse than I am. And JL's proposal would let one implement that. On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca jlaba...@google.com wrote: I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken sven.brun...@googlemail.com wrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I think that violates the spirit, if not the letter, of the addHandler() contract. I add a handler and I get back a HandlerRegistration. I can use that registration to remove the handler later, if I choose to do so. If I expose that registration to other code, then the other code can also remove the handler. But if I guard my registration jealously, I expect that nobody else will have the ability to remove my handler. It seems to me that canceling all of the old handlers when the manager changes is a recipe for hard to find bugs, especially if changing HandlerManagers is not a common use case. You're going to have handlers suddenly stop receiving events and not be able to find an explicit removal. On Thu, Feb 11, 2010 at 11:36 AM, Arthur Kalmenson arthur.k...@gmail.com wrote: But what if you have the case where you're setting the HandlerManager specifically because you want to stop listening to all the events from the previous HandlerManager. The idea of a stack of HandlerManagers makes some sense if you want to have different HandlerManagers handling events for different parts of a system. I understand the idea of making your own HandlerManager, but from a design perspective, doesn't it make sense to just have a singleton HandlerManager? Are there performance implications of having everything go through one HandlerManager? All the best, -- Arthur Kalmenson On Wed, Feb 10, 2010 at 11:34 AM, Isaac Truett itru...@gmail.com wrote: The argument seems to revolve around changing HandlerManagers resulting in the loss of registered handlers. Is it possible that the HandlerManager and the set of registered handlers aren't really the same thing and need to be separated? Would everyone be happy if you could call setHandlerManager() and the new manager would still service the same set of handlers that existed previously? On Wed, Feb 10, 2010 at 10:59 AM, Ray Ryan rj...@google.com wrote: I forgot about that nuance of your proposal. I like. @jat: the stack idea is nifty, but expanding the scope of the patch even worse than I am. And JL's proposal would let one implement that. On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca jlaba...@google.com wrote: I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken sven.brun...@googlemail.com wrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events they
source, copying some handlers or not if that's appropriate (perhaps in mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override createHM() I
can provide a custom implementation, or wrap the normal one, without having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events they
source, copying some handlers or not if that's appropriate (perhaps in mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override createHM() I
can provide a custom implementation, or wrap the normal one, without having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I don't get that. If I (widget) have nothing to say to you for a while (am
not going to be generating the kinds of events that you are registered for),
why do you care if my mechanism for achieving that involves putting my usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while (am
not going to be generating the kinds of events that you are registered for),
why do you care if my mechanism for achieving that involves putting my usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Make HandlerManager survive exceptions
The new patch set looks great. Thanks, Pete. http://gwt-code-reviews.appspot.com/136805 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Make HandlerManager survive exceptions
One more tweak, though: http://gwt-code-reviews.appspot.com/136805/diff/5001/5002 File user/src/com/google/gwt/event/shared/HandlerManager.java (right): http://gwt-code-reviews.appspot.com/136805/diff/5001/5002#newcode71 Line 71: causes.add(e); Seems like this and the identical call below should be refactored into a single method http://gwt-code-reviews.appspot.com/136805 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Your point being that I could just implement a custom handler manager that
can do any of these things, and so should keep Widgets that much simpler,
yes? I don't have a good answer to that.
On Thu, Feb 11, 2010 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while
(am
not going to be generating the kinds of events that you are registered
for),
why do you care if my mechanism for achieving that involves putting my
usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com
wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet
to
define policies of their own.
E.g., to temporarily switch between modes that change the set of
events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying
it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is
called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Make HandlerManager survive exceptions
Oh, course, nevermind, LGTM On Thu, Feb 11, 2010 at 12:01 PM, Pete Hopkins phopk...@google.com wrote: On Thu, Feb 11, 2010 at 2:58 PM, rj...@google.com wrote: One more tweak, though: http://gwt-code-reviews.appspot.com/136805/diff/5001/5002 File user/src/com/google/gwt/event/shared/HandlerManager.java (right): http://gwt-code-reviews.appspot.com/136805/diff/5001/5002#newcode71 Line 71: causes.add(e); Seems like this and the identical call below should be refactored into a single method That's tricky to do because the causes variable needs to get initialized from the common code. I don't think causes can be made a member variable because that method needs to be reentrant. The alternative would be passing in causes and then returning it from the helper method (so that the helper could initialize it), or doing away with the optimization of only creating causes when it's needed. -- Pete -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I was actually thinking it would involve overriding onBrowserEvent().
Maybe I need to have another look at how HandlerManager fits into
things. I thought of it more as a dispatcher directing traffic than
the actual source of event firing. But yes, essentially, it looks like
all of the tools are there already to turn off one type of event and
turn on another. The handlers for the off event don't fire because
their event simply doesn't happen. Then you don't have to worry about
which HM is active when a handler is added, making sure they get
removed properly, etc. Simpler, as you said.
On Thu, Feb 11, 2010 at 3:30 PM, Ray Ryan rj...@google.com wrote:
Your point being that I could just implement a custom handler manager that
can do any of these things, and so should keep Widgets that much simpler,
yes? I don't have a good answer to that.
On Thu, Feb 11, 2010 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while
(am
not going to be generating the kinds of events that you are registered
for),
why do you care if my mechanism for achieving that involves putting my
usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com
wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet
to
define policies of their own.
E.g., to temporarily switch between modes that change the set of
events
they
source, copying some handlers or not if that's appropriate (perhaps
in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g.,
to
try
out a singleton HM (I wouldn't, but why should I stop you from trying
it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is
called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal
createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
If you need to swap out two different complex event handling modes of
a widget (where say, a half dozen different events are being
monitored), I think it is too complex to remove all the old handlers
and add new ones every time, I also think overriding onBrowserEvent is
kind of tedious and limited, since every time you need to change the
set being nullified or altered, you need to edit the method.
Consider a paint program with a paint widget, where, depending on
which tool is selected (clone, crop, airbrush, etc) a different set of
event handlers will be active. On some, you may care about drag, or
keyboard, or mouse wheel, or others, you don't.
You could of course write an object that absorbs all the events and
re-routes/broadcasts them as needed, but then all you've done is
simply re-invent HandlerManager and called it 'EventRouter' or some
subject.
Ray * Ray = Ray ^2
:)
On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote:
I was actually thinking it would involve overriding onBrowserEvent().
Maybe I need to have another look at how HandlerManager fits into
things. I thought of it more as a dispatcher directing traffic than
the actual source of event firing. But yes, essentially, it looks like
all of the tools are there already to turn off one type of event and
turn on another. The handlers for the off event don't fire because
their event simply doesn't happen. Then you don't have to worry about
which HM is active when a handler is added, making sure they get
removed properly, etc. Simpler, as you said.
On Thu, Feb 11, 2010 at 3:30 PM, Ray Ryan rj...@google.com wrote:
Your point being that I could just implement a custom handler manager that
can do any of these things, and so should keep Widgets that much simpler,
yes? I don't have a good answer to that.
On Thu, Feb 11, 2010 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while
(am
not going to be generating the kinds of events that you are registered
for),
why do you care if my mechanism for achieving that involves putting my
usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com
wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet
to
define policies of their own.
E.g., to temporarily switch between modes that change the set of
events
they
source, copying some handlers or not if that's appropriate (perhaps
in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g.,
to
try
out a singleton HM (I wouldn't, but why should I stop you from trying
it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is
called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal
createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
But I could still override createHM to be a wrapper that is backed by two separate instances, for example. I'm running out of rationalizations for providing both methods. And if getHM is missed it could be added later. 180 degrees, rjrjr On Feb 11, 2010 1:00 PM, Ray Cromwell cromwell...@gmail.com wrote: If you need to swap out two different complex event handling modes of a widget (where say, a half dozen different events are being monitored), I think it is too complex to remove all the old handlers and add new ones every time, I also think overriding onBrowserEvent is kind of tedious and limited, since every time you need to change the set being nullified or altered, you need to edit the method. Consider a paint program with a paint widget, where, depending on which tool is selected (clone, crop, airbrush, etc) a different set of event handlers will be active. On some, you may care about drag, or keyboard, or mouse wheel, or others, you don't. You could of course write an object that absorbs all the events and re-routes/broadcasts them as needed, but then all you've done is simply re-invent HandlerManager and called it 'EventRouter' or some subject. Ray * Ray = Ray ^2 :) On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote: I was actually thinking... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Does anyone object to adding createHandlerManager now, and then adding getHandlerManager if it is needed later? Thanks, John LaBanca jlaba...@google.com On Thu, Feb 11, 2010 at 4:09 PM, Ray Ryan rj...@google.com wrote: But I could still override createHM to be a wrapper that is backed by two separate instances, for example. I'm running out of rationalizations for providing both methods. And if getHM is missed it could be added later. 180 degrees, rjrjr On Feb 11, 2010 1:00 PM, Ray Cromwell cromwell...@gmail.com wrote: If you need to swap out two different complex event handling modes of a widget (where say, a half dozen different events are being monitored), I think it is too complex to remove all the old handlers and add new ones every time, I also think overriding onBrowserEvent is kind of tedious and limited, since every time you need to change the set being nullified or altered, you need to edit the method. Consider a paint program with a paint widget, where, depending on which tool is selected (clone, crop, airbrush, etc) a different set of event handlers will be active. On some, you may care about drag, or keyboard, or mouse wheel, or others, you don't. You could of course write an object that absorbs all the events and re-routes/broadcasts them as needed, but then all you've done is simply re-invent HandlerManager and called it 'EventRouter' or some subject. Ray * Ray = Ray ^2 :) On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote: I was actually thinking... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I agree, you could do it that way. I'm trying to think of a case where it wouldn't be good enough, I guess in theory, you could have a widget that can't be subclassed/overridden where set/get methods could allow you to override or inject HM dependencies, whereas the create technique isn't as DI friendly. -Ray On Thu, Feb 11, 2010 at 1:09 PM, Ray Ryan rj...@google.com wrote: But I could still override createHM to be a wrapper that is backed by two separate instances, for example. I'm running out of rationalizations for providing both methods. And if getHM is missed it could be added later. 180 degrees, rjrjr On Feb 11, 2010 1:00 PM, Ray Cromwell cromwell...@gmail.com wrote: If you need to swap out two different complex event handling modes of a widget (where say, a half dozen different events are being monitored), I think it is too complex to remove all the old handlers and add new ones every time, I also think overriding onBrowserEvent is kind of tedious and limited, since every time you need to change the set being nullified or altered, you need to edit the method. Consider a paint program with a paint widget, where, depending on which tool is selected (clone, crop, airbrush, etc) a different set of event handlers will be active. On some, you may care about drag, or keyboard, or mouse wheel, or others, you don't. You could of course write an object that absorbs all the events and re-routes/broadcasts them as needed, but then all you've done is simply re-invent HandlerManager and called it 'EventRouter' or some subject. Ray * Ray = Ray ^2 :) On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote: I was actually thinking... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
@John - No objection here. @Ray squared - The idea of overriding HandlerManager still intrigues me. I've never found myself wanting to do it and I don't recall seeing it in practice elsewhere. I'm curious. If either of you knows of a project where I could find an example, would you mind passing along a link? On Thu, Feb 11, 2010 at 4:52 PM, John LaBanca jlaba...@google.com wrote: Does anyone object to adding createHandlerManager now, and then adding getHandlerManager if it is needed later? Thanks, John LaBanca jlaba...@google.com On Thu, Feb 11, 2010 at 4:09 PM, Ray Ryan rj...@google.com wrote: But I could still override createHM to be a wrapper that is backed by two separate instances, for example. I'm running out of rationalizations for providing both methods. And if getHM is missed it could be added later. 180 degrees, rjrjr On Feb 11, 2010 1:00 PM, Ray Cromwell cromwell...@gmail.com wrote: If you need to swap out two different complex event handling modes of a widget (where say, a half dozen different events are being monitored), I think it is too complex to remove all the old handlers and add new ones every time, I also think overriding onBrowserEvent is kind of tedious and limited, since every time you need to change the set being nullified or altered, you need to edit the method. Consider a paint program with a paint widget, where, depending on which tool is selected (clone, crop, airbrush, etc) a different set of event handlers will be active. On some, you may care about drag, or keyboard, or mouse wheel, or others, you don't. You could of course write an object that absorbs all the events and re-routes/broadcasts them as needed, but then all you've done is simply re-invent HandlerManager and called it 'EventRouter' or some subject. Ray * Ray = Ray ^2 :) On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote: I was actually thinking... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I'd say that if you wanted to implement a HandlerManager stack, it
would probably be best to do that internal to the HandlerManager,
rather than forcing a Widget to know how events are handled.
Assuming that is possible given the current Widget implementations
(others more expert than I would know this, probably), the only API I
would want is createHandlerManager(). I could then manage how that
more complex HandlerManager is dealt with.
While we're on the subject... if you're providing this factory method,
I would rather see a well-documented interface to implement rather
than a semi-documented implementation of which I would probably be
overriding every method.
just my .02
On Feb 11, 11:05 am, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events they
source, copying some handlers or not if that's appropriate (perhaps in mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override createHM() I
can provide a custom implementation, or wrap the normal one, without having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Alright, lets go with createHandlerManager() for now. Thanks for all the
feedback.
@sven -
Would you like to update the patch by reverting the getHandlerManager()
method back to a package protected method? If you don't get to it for a few
days, I'll can do it for you.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, Feb 11, 2010 at 9:39 PM, Nathan Wells nwwe...@gmail.com wrote:
I'd say that if you wanted to implement a HandlerManager stack, it
would probably be best to do that internal to the HandlerManager,
rather than forcing a Widget to know how events are handled.
Assuming that is possible given the current Widget implementations
(others more expert than I would know this, probably), the only API I
would want is createHandlerManager(). I could then manage how that
more complex HandlerManager is dealt with.
While we're on the subject... if you're providing this factory method,
I would rather see a well-documented interface to implement rather
than a semi-documented implementation of which I would probably be
overriding every method.
just my .02
On Feb 11, 11:05 am, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Thinking outload...
What about allowing ctors to take a HM. The other ctors use the default
implementation. If you dont care for a HM then use the ctors without HM in
the parameter list. That way you dont pollute the widget method list with
gets/creates and sets which prolly dont make sense once the thing is built.
On Fri, Feb 12, 2010 at 2:22 PM, John LaBanca jlaba...@google.com wrote:
Alright, lets go with createHandlerManager() for now. Thanks for all the
feedback.
@sven -
Would you like to update the patch by reverting the getHandlerManager()
method back to a package protected method? If you don't get to it for a few
days, I'll can do it for you.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, Feb 11, 2010 at 9:39 PM, Nathan Wells nwwe...@gmail.com wrote:
I'd say that if you wanted to implement a HandlerManager stack, it
would probably be best to do that internal to the HandlerManager,
rather than forcing a Widget to know how events are handled.
Assuming that is possible given the current Widget implementations
(others more expert than I would know this, probably), the only API I
would want is createHandlerManager(). I could then manage how that
more complex HandlerManager is dealt with.
While we're on the subject... if you're providing this factory method,
I would rather see a well-documented interface to implement rather
than a semi-documented implementation of which I would probably be
overriding every method.
just my .02
On Feb 11, 11:05 am, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
mP
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Yes, many times its too hard to customize things. Sometimes it make sense to use private or package protected. But i think the HandlerManager gets used so widely that it should be customizable On 9 Feb., 23:57, Nathan Wells nwwe...@gmail.com wrote: As a developer I absolutely agree with Mr. Ryan here... I hope that this isn't taken the wrong way, but it's so difficult to customize any given tool that GWT hands us. The eventual answer always seems to be make a custom build which is extremely hard to sell to anyone other than a GWT developer. For additional related information, see the following issue: http://code.google.com/p/google-web-toolkit/issues/detail?id=3628 On Feb 9, 10:14 am, Ray Ryan rj...@google.com wrote: On Tue, Feb 9, 2010 at 9:09 AM, jlaba...@google.com wrote: Warning: better arguments against setHandlerManager below: My concern is that it is too easy to add handlers to a Widget and then set a new HandlerManager, expecting the old handlers to be transferred to the new HandlerManager. What would be the correct thing to do here? We can't transfer handlers because the HandlerRegistrations are linked to the old HandlerManager. Why would I expect that? I'd use such a call expecting it to allow me to swap different sets of handlers around, e.g. a widget that has two very different modes (edit v. nav). Also, we've been trying to move to a model where we add Event Handlers in a widget's constructor instead of overriding onBrowserEvent(). Those handlers will be lost when we switch to a new HandlerManager, unless we unregister the old ones and register new ones. That complicates the widget creation process. I hope you mean add event handling capabilities at constructor time, not actual handler instances. If you mean the latter, that's a dreadful idea. I still don't buy this argument. If I swap it out, I can swap it in. If we require that the user specify the one and only HandlerManager when the first handler is added, then we avoid these problems. I really think this is over protective, and the kind of thing that makes our widgets too hard to customize. http://gwt-code-reviews.appspot.com/138801 -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
On 2010/02/09 16:46:27, Ray Ryan wrote: Sorry, I came in mid-conversation. My -1 was in defense of setHandlerManager(), seeing no harm in allowing a widget to swap around its HM if it wants to. I'm totally in favor of allowing a custom HM to be used. For the ListModel also an own HandlerRegistration (ListRegistration) and an own HandlerManager will be needed. I think it is a good point to open it up for widgets too. I will change the patchfile to use a createHandlerManager method. http://gwt-code-reviews.appspot.com/138801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
My last two cents: This discussion is a classic example of why the GWT widgets are so locked down. GWT Contributors, do you trust yourselves or don't you? On Wed, Feb 10, 2010 at 7:27 AM, Andi Mullaraj andimulla...@gmail.comwrote: Hi Ray, all, I believe changing HMs mid stream is dangerous: 1. Say your (nav edit) widget fires events that are common to both modes (i.e. a simple onOpen) and the widget is by default in nav mode 2 Say A registers an onOpen handler (which gets added to hm1 -- the default HM) then later switches to edit mode (and hm2 kicks in) 3. A will not see the onOpen events while on edit mode! If your nav edit widet stays always in one mode, then createHM would do the trick. But if it switches modes you have to make sure there is no overlapping sets of events ... Andi On Tue, Feb 9, 2010 at 11:55 AM, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
On Wed, Feb 10, 2010 at 10:27 AM, Andi Mullaraj andimulla...@gmail.comwrote: I believe changing HMs mid stream is dangerous: 1. Say your (nav edit) widget fires events that are common to both modes (i.e. a simple onOpen) and the widget is by default in nav mode 2 Say A registers an onOpen handler (which gets added to hm1 -- the default HM) then later switches to edit mode (and hm2 kicks in) 3. A will not see the onOpen events while on edit mode! If your nav edit widet stays always in one mode, then createHM would do the trick. But if it switches modes you have to make sure there is no overlapping sets of events ... Another option to achieve this with potentially less danger is to maintain a stack of HandlerManagers. If one HM doesn't handle an event, it goes down to the next one. Then, if you want to have some modal event handling logic, you push a new HM on the stack with its own set of event handlers. When you are done with the modal logic, you pop it off the stack. Event types not handled by the modal event handler fall through to the main one, so in your example onOpen would still get handled properly. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken sven.brun...@googlemail.comwrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I forgot about that nuance of your proposal. I like. @jat: the stack idea is nifty, but expanding the scope of the patch even worse than I am. And JL's proposal would let one implement that. On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca jlaba...@google.com wrote: I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken sven.brun...@googlemail.com wrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
On Wed, Feb 10, 2010 at 10:56 AM, John LaBanca jlaba...@google.com wrote: We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. The javadoc for getHandlerManager would have to say that the result can't be cached and should be called each time you need one. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
@John: hm2 could indeed handle onOpen and hm1 would never get a chance to notify its registered handlers :( So I'd gues the event has to be pushed down in all cases ... which pretty much takes us to one HM setup. I also think that createHM is enough. In general, though components usually have setters/getters for their properties, a good API makes obvious where the developer has to interveene (in the setters or getters) in order to customize. In particular, if we had a createHM, wouldn't it defy the purpose to have an (overridable) getHM. In other words, why not have getHM replace the createHM? Andi On Wed, Feb 10, 2010 at 10:54 AM, John Tamplin j...@google.com wrote: On Wed, Feb 10, 2010 at 10:27 AM, Andi Mullaraj andimulla...@gmail.comwrote: I believe changing HMs mid stream is dangerous: 1. Say your (nav edit) widget fires events that are common to both modes (i.e. a simple onOpen) and the widget is by default in nav mode 2 Say A registers an onOpen handler (which gets added to hm1 -- the default HM) then later switches to edit mode (and hm2 kicks in) 3. A will not see the onOpen events while on edit mode! If your nav edit widet stays always in one mode, then createHM would do the trick. But if it switches modes you have to make sure there is no overlapping sets of events ... Another option to achieve this with potentially less danger is to maintain a stack of HandlerManagers. If one HM doesn't handle an event, it goes down to the next one. Then, if you want to have some modal event handling logic, you push a new HM on the stack with its own set of event handlers. When you are done with the modal logic, you pop it off the stack. Event types not handled by the modal event handler fall through to the main one, so in your example onOpen would still get handled properly. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
The argument seems to revolve around changing HandlerManagers resulting in the loss of registered handlers. Is it possible that the HandlerManager and the set of registered handlers aren't really the same thing and need to be separated? Would everyone be happy if you could call setHandlerManager() and the new manager would still service the same set of handlers that existed previously? On Wed, Feb 10, 2010 at 10:59 AM, Ray Ryan rj...@google.com wrote: I forgot about that nuance of your proposal. I like. @jat: the stack idea is nifty, but expanding the scope of the patch even worse than I am. And JL's proposal would let one implement that. On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca jlaba...@google.com wrote: I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken sven.brun...@googlemail.com wrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Add the ability to change the default HandlerManager of a Widget
Instead of having a setHandlerManager() method, which can be called
twice, I think we should have a protected createHandlerManager() method
that is called from ensureHandlerManager(). That way, we can ensure it
is only called once:
HandlerManager createHandlerManager() {
return new HandlerManager(this);
}
I think the protected getHandlerManager() method makes sense.
http://gwt-code-reviews.appspot.com/138801/diff/1/2
File user/src/com/google/gwt/user/client/ui/Widget.java (right):
http://gwt-code-reviews.appspot.com/138801/diff/1/2#newcode247
Line 247: * Returns the handler manager
Checkstyle requires a period at the end of this sentence.
http://gwt-code-reviews.appspot.com/138801
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
-1 Why? What problem is this fixing? http://gwt-code-reviews.appspot.com/138801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Sorry, I came in mid-conversation. My -1 was in defense of setHandlerManager(), seeing no harm in allowing a widget to swap around its HM if it wants to. I'm totally in favor of allowing a custom HM to be used. http://gwt-code-reviews.appspot.com/138801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Sven had a use case for doing this that we talked about in another thread (which I just forwarded to gwt-contrib): https://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/888ae5ec54a7a8da Basically, he has a more advanced HandlerManager that he wants to use. We told him to add a patch to rietveld to get gwt-contrib input, and nobody nobody complained. Personally, I don't think its fine to allow users to provide their own HandlerManager. Thanks, John LaBanca jlaba...@google.com On Tue, Feb 9, 2010 at 11:31 AM, rj...@google.com wrote: -1 Why? What problem is this fixing? http://gwt-code-reviews.appspot.com/138801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I am against the wimpy runtime assertion in Sven's patch, since assertaions may be disasbled. I think that swapping out a HandlerManager is inviting problems for developers, and I can't think of a good use case for it. If we are only going to allow one HandlerManager, it should be baked into the API. http://gwt-code-reviews.appspot.com/138801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Warning: better arguments against setHandlerManager below: My concern is that it is too easy to add handlers to a Widget and then set a new HandlerManager, expecting the old handlers to be transferred to the new HandlerManager. What would be the correct thing to do here? We can't transfer handlers because the HandlerRegistrations are linked to the old HandlerManager. Also, we've been trying to move to a model where we add Event Handlers in a widget's constructor instead of overriding onBrowserEvent(). Those handlers will be lost when we switch to a new HandlerManager, unless we unregister the old ones and register new ones. That complicates the widget creation process. If we require that the user specify the one and only HandlerManager when the first handler is added, then we avoid these problems. http://gwt-code-reviews.appspot.com/138801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
On Tue, Feb 9, 2010 at 9:09 AM, jlaba...@google.com wrote: Warning: better arguments against setHandlerManager below: My concern is that it is too easy to add handlers to a Widget and then set a new HandlerManager, expecting the old handlers to be transferred to the new HandlerManager. What would be the correct thing to do here? We can't transfer handlers because the HandlerRegistrations are linked to the old HandlerManager. Why would I expect that? I'd use such a call expecting it to allow me to swap different sets of handlers around, e.g. a widget that has two very different modes (edit v. nav). Also, we've been trying to move to a model where we add Event Handlers in a widget's constructor instead of overriding onBrowserEvent(). Those handlers will be lost when we switch to a new HandlerManager, unless we unregister the old ones and register new ones. That complicates the widget creation process. I hope you mean add event handling capabilities at constructor time, not actual handler instances. If you mean the latter, that's a dreadful idea. I still don't buy this argument. If I swap it out, I can swap it in. If we require that the user specify the one and only HandlerManager when the first handler is added, then we avoid these problems. I really think this is over protective, and the kind of thing that makes our widgets too hard to customize. http://gwt-code-reviews.appspot.com/138801 -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
