On Thursday, December 23, 2010 3:38:12 AM UTC+1, sunny...@gmail.com wrote:
>
> Hi everyone, 
>
> Before 2.1 I created an application that use the "old" MVP 
> architecture of having models, views and presenters. This worked quite 
> well. I'm migrating this application to use the 2.1 MVP framework now. 
> I've made some progress but am still getting my head around it. 
>
> This has hit me so far: in my old code, the presenter was responsible 
> for setting the listeners/handlers on the view/eventbus respectively. 
> Where appropriate handlers would be removed when the view changed so 
> that events are not handled more than once. (eg, I destroy my login 
> window once login succeeds, and I also remove the eventbus 
> LoginSucceededEvent handler, so after logging out there aren't two of 
> them listening on the eventbus) 
>
> Here is the start method of the apps' login activity: 
> @Override 
> public void start(AcceptsOneWidget panel, EventBus eventBus) { 
> LoginView view = clientFactory.getLoginView();  // just one instance 
> bindView(view);   // eg, view.getButton().addClickHandler(... 
> bindEvents(view, eventBus);   // eg, eventBus.addHandler(.... 
> panel.setWidget(view.asWidget()); 
> } 
>
> The LoginView is reused from the ClientFactory as the documentation 
> suggests. This raises two questions: 
>
> 1) I would like to keep the GUI bindings outside the UI code (just as 
> I did in the old code where it was in the presenter). But since the 
> documentation suggests using a single instance of a the views, here I 
> would be adding more and more listeners each time the activity is 
> initialised (as they are in the ActivityMapper). The HelloMVP example 
> has the binding code in the view and allows the view to communicate 
> with the activity. Can this be avoided? It would help in keeping the 
> UI code strictly to UI and presentation. Short of implementing a 
> method on all views that clear its listeners I cannot think of a 
> better way (I would still think this to be cumbersome - its not 
> something you'd normally do)
>

First, you have to understand the "why" of this suggestion: everything 
DOM-related is slow. This means that creating a view is slow (compared to 
creating any other "POJO", such as your presenters/activities).
Having initially worked with the HasXxxHandlers approach (MVP tutorial - 
part 1) and later switched to the "delegates" approach (quite some time 
before the MVP tutorial - part 2 and places & activities tutorials were 
written), I assure you that writing unit tests is waaaay easier with the 
latter ! (I also find the presenter code more readable, and it allows using 
@UiHandler methods in your view if you use UiBinder). If you want to make 
the switch, I assure you you won't regret it.

That being said, you're not forced to do the switch. If you want to keep 
your addXxxHandler calls in your presenter, then you'll have to remove them 
when the activity is over. This means keeping a reference to every 
HandlerRegistration returned by the addXxxHandler calls, and call 
removeHandler in each one from the onStop and onCancel methods of the 
activity.
Someone posted (a few months back, maybe it was even last year) a 
HandlerRegistration "holder", where you add your HandlerRegistration objects 
(e.g. holder.add(view.saveButton().addClickHandler(...)), so you only have a 
single call to holder.removeHandlers() in your onStop/onCancel. This is an 
approach that has been used by MVP frameworks such as gwt-mvp and 
gwt-platform too (but I don't think it's re-usable outside those 
frameworks).
 

> 2) Similar issue with eventbus handlers - I can't wrap the eventbus in 
> a ResettableEventBus as I don't want to wipe all handlers off the 
> eventbus, nor do I want to have to manually deal with each handler in 
> onStop of the Activity.
>

As Y2i said, this is actually not an issue as the EventBus you get passed in 
onStart *is* a ResettableEventBus.

I don't understand why the ResettableEventBus is an issue for you though… 
(activities are meant to be thrown away once they're stopped/cancelled, 
they're specifically not meant to be re-used)

-- 
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.

Reply via email to