Don't have much to add that the other reviewers haven't already poked
at.
I still echo the sentiment that it feels weird to have widgets chatting
by default on the global event bus. But I think that should be part of a
separate broader discussion.
http://gwt-code-reviews.appspot.com/1449817/diff/4001/user/src/com/google/gwt/user/client/ui/Widget.java
File user/src/com/google/gwt/user/client/ui/Widget.java (right):
http://gwt-code-reviews.appspot.com/1449817/diff/4001/user/src/com/google/gwt/user/client/ui/Widget.java#newcode302
user/src/com/google/gwt/user/client/ui/Widget.java:302:
this.eventSourceName = eventSourceName;
This scheme seems brittle. How do we prevent collisions?
http://gwt-code-reviews.appspot.com/1449817/diff/4001/user/src/com/google/gwt/user/client/ui/Widget.java#newcode320
user/src/com/google/gwt/user/client/ui/Widget.java:320: driver.start();
In addition to the potential for out of syncness. Are there not
situations where you want the driver to be active when the widget is
invisible? I can imagine a presenter managing some state and firing
events, but simply not needing to update UI.
Also, this change means that subsequent calls to setVisible(true/false)
will not be idempotent... is that ok?
On 2011/06/14 18:34:41, rjrjr wrote:
How about protected boolean isActive() method, with a default
implementation
based on attached and visible? This setVisible method might become:
if ((driver != null) && isActive()) {
startDriver();
}
super.setVisible(visible);
if ((driver != null) && !isActive()) {
stopDriver();
}
http://gwt-code-reviews.appspot.com/1449817/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
