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;
If you're talking specifically about requiring strings, I've given up on
that. Is that what you meant?
On 2011/06/17 04:32:45, jaimeyap wrote:
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();
On 2011/06/17 04:32:45, jaimeyap wrote:
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.
That's why it's called "Driver" and not "Presenter." If tying the
Presenter's activation to its View's visibility isn't useful to a
Presenter / View pair, there is no need for them to use that hook. There
is no code here decreeing that every presenter is also the driver for
its widget, just some javadoc suggesting it as a convention. In your
case, the setPresenter(Presenter p) method leaves out the
this.setDriver(p) call.
But all that said, I am concerned that I'm forcing one solution to two
or three problems. 1) We have no consistent convention for telling if a
view is active, 2) it's hard to clean up dangling handlers and
unfinished async calls when a presenter loses control. Plus a helping of
3) it's hard to tell when a GWT widget is relevant.
I'm thinking that what's really needed is a general notion of a job
context. As a presenter, I have a job. I get told when to start and to
stop, sometimes because the place has changed, sometimes because a
widget is awake, sometimes because [fill in blank.] While I'm awake I
can register event handlers and fire off async requests and [fill in
blank] without having to worry about cleaning them up when the job ends.
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
