For context, this is what Zach is implementing:
My team has been struggling a bit to find a way to handle
interactions between controllers and views smoothly. We've ended up
with a lot of code in one of two styles:
class FooController {
void onFirstRender {
view.addClickHandlerToSomeButton(new ClickHandler()
{ handleEvent(ClickEvent e) { /* ... */ } });
}
}
or
class FooView {
private FooController controller;
@UiHandler("fooElement")
void handleClick(ClickEvent e) {
controller.doSomething();
}
}
We do not love either of these styles -- the first one is very
cumbersome, since we have to add methods to the view, and the second
one is nasty because it makes it easy for business logic to leak into
the view. We really don't want our views to store references to their
controllers.
After hashing this out with a few devs, we came up with a compromise
that we like:
class FooController {
@UiHandler("someElementInView")
public void handleClick(ClickEvent e) {
doSomeControllerLogic();
}
}
class FooView {
@UiHandler("someOtherElement")
public void handleClick(ClickEvent e) {
doViewSpecificLogicOnly();
}
}
This requires a little bit of modification to UiBinder. I have a hacky
CL that allows this, by letting the view use a "ControlledUiBinder"
rather than a UiBinder that points the code generator to the
controller and adds hooks for those handlers, then putting a UiBinder
on the controller that places those handlers on the view's binder.
Before I turn this into a 'ready-for-prime-time' CL, does this sound
like a reasonable change? The existing UiBinder syntax remains the
same, but there are two new interfaces extending it that can be used
instead. And there's no more calls to setController(), circular
generics, or business logic in the view (all problems my team has
had).
I can go into more detail if people are interested. I just wanted to
float an idea balloon.
http://gwt-code-reviews.appspot.com/923801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
