Thanks Thomas and Y2i - shortly after I posted I read in the API that the EventBus passed in onStart is a ResettableEventBus (that wraps the EventBus given in the ActivityManager?)
My application is a tabbed application (its quite good for our workflow) with a secure login. There is a full screen login widget, and that is replaced by a SmartGWT TabSet once the login succeeds. Tabs are generated once the user logs in based on their permissions. Each tab also has its own Activity+View. The TabSet is only simulated, there is only one content panel which is used by the ActivityManager to change the View. The TabSet has listeners on PlaceChangeEvent and change the selected tab accordingly. The way I've approached this as a first pass test is that there is a PlaceController+ActivityMapper+ActivityManager+EventBus for going between the login page and the TabSet. There is also a second set of PlaceController+ActivityMapper+ActivityManager+EventBus thats used by the TabSet itself to go between the different tabs. Amazingly this works really well - logging in, switching tabs, and logging out all works wonderfully. However, history falls apart. I would have hoped the back/forward buttons take me through the tabs (I can see the tokens appearing correctly in the address bar). atm I also have two PlaceHistoryHandlers - I'm assuming this is where my problem is. Unfortunately I think I simply don't have a good enough understanding of the interaction of these new classes to make an informed choice on what I should be doing. 1) Judging from the PlaceHistoryHandler source each instance of PlaceHistoryHandler should receive the change event - do I need a more sophisticated Historian to handle whether the change event (eg, just a tab changing, or logging out) should be handled by that PlaceHistoryHandler? 2) Having two PlaceControllers seems illogical to me, but this was a side effect of having two PlaceHistoryHandlers. I think I'm quite confused here as to how it should come together? Sunny On Dec 23, 8:51 pm, Thomas Broyer <[email protected]> wrote: > On Thursday, December 23, 2010 3:38:12 AM UTC+1, [email protected] 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 [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.
