oh, not sure why I didn't think of this earlier, the EventBus is a
perfect way to handle this (well, it's pretty good anyway :) )
so instead of:
public void setSaveCancelHandler(SaveCancelHandler handler) {
this.handler = handler;
}
you could just do:
SaveCancelEvent event = new SaveCancelEvent();
eventBus.fireEvent(event);
of course this assumes you are fine with making event APIs for your
displays.
and you don't have to have your Display keeping track of instances of
listeners on it. That, and anyone can listen to your events,
although, usually I would think only your Presenter would be
listening.
cheers
-bryce
On Dec 28, 12:25 am, bcottam <bcot...@gmail.com> wrote:
> 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 <jonas.huckest...@me.com> 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 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.
