just following up on this. I've just started using the UiBinder and
love it. I really like how clean it makes my UI code. However, I was
kind of struggling with the @UiHandler annotation and how it fit in
with the whole MVP paradigm as well. Your suggestion Jonas is great
(i.e. reversing the MVP dependency linkage) however, I wonder if a
more decoupled approach may be appropriate. For instance, I really
like the idea that I can make a UI interface that defines properties
(getName() setName() etc) rather than HTML DOM elements
(getNameTextField() etc.) so I don't want to be putting my UI class in
charge of migrating data from my ui inputs to my presenter. So, I
thought, perhaps some really simple event driven api might work:
public class MyPresenter implements SaveCancelHandler {
public interface Display {
public String getName();
public void setName(String name);
....
}
public void saveClicked(ClickEvent event) {
....
}
public void cancelClicked(ClickEvent event) {
....
}
}
public class MyPanel extends Composite implements MyPresenter.Display
{
@UiField TextBox nameBox;
@UiField Button saveButton;
@UiField Button cancelButton;
private SaveCancelHandler handler;
public void setSaveCancelHandler(SaveCancelHandler handler) {
this.handler = handler;
}
public void setName(String name) {
nameBox.setText(name);
}
public String getName() {
return nameBox.getText();
}
@UiHandler("saveButton")
public void saveClicked(ClickEvent event) {
handler.saveClicked(event);
}
@UiHandler()
public void cancelClicked(ClickEvent event) {
handler.cancelClicked(event);
}
}
// this could be a nested class, but this one seems really common:
public interface SaveCancelHandler {
public void saveClicked(ClickEvent event);
public void cancelClicked(ClickEvent event);
}
of course, this could be done with some more elegant events/handler
definitions etc and perhaps a nice HandlerManager so multiple Handlers
could be added to your display. This eliminates the anonymous class
definitions and leaves both your UI and Presenter with a rather clean
api. I'm playing around with this pattern now, so I don't know if
there is some pitfall waiting to bite me, but so far it's working well
and I like it *lots* better than this stuff:
getDisplay().addSaveHandler( new ClickHandler() {
public void onClick(ClickEvent event) {
saveClicked(event);
}
});
On Dec 15, 1:41 am, Jonas Huckestein <[email protected]> wrote:
> > One question .. how does using @UiHandlerin the View code maintain
> > MVP? I would like to stick to @UiHandlerannotation, but it seems to
> > me that testing will get hurt. My current thinking is going with
> > something similar to what Thomas described above.
>
> I recall having read on the gin list a couple of months ago, that it
> might be useful to reverse the dependency of the view andpresenterin
> MVP. You could inject a "presenter" class into the class containing
> the @UiHandlerannotations and from the view call methods on thepresenter. I
> have to figure this out in the next couple of weeks since
> I am not yet sure about a lot of things. For instance, does thepresenterneed
> to know about the view class or can it be agnostic by
> requiring all data to be passed to its methods? This would remove the
> need to have hundreds of *.Display interfaces and would make testing
> easier since it would not require that much mocking.
>
> And here is a slightly different question: Does anyone have experience
> with how fast the HTMLUnit tests can run? My feeling is, that the plan
> for GWT might be to move away from hacks like MVP alltogether. I think
> the annotation-style of UI bindings is also well suited to build
> automated tests on mock UIs in the future and my feeling is that
> sticking close to all of UiBinder's features might not be a bad
> idea ...
>
> In case anyone is interested, I could try to pretty up the framework
> code we currently use for a large GWT 2 application and perhaps post
> it here or soething (I will have to check that with my team though ;))
>
> Cheers, Jonas
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
