MVP in GWT : Best design practice

Question

I have read on MVP tutorial of GWT project site that, view should only contain event handlers for widgets it contain and logic for handling them should reside in presenter. Regarding this i have below doubts :

1. Many times we need to dynamically change the style of widgets on the basis of events received on view, so does it make sense to move this kind of logic in prsenter ?

2. Many times we need to get data from several fields in view and create a object and pass it to some widget, like a cellTable, which has its own asyncDataProvider. So does it make sense in creating getters and setters for all view fields, so that presenter can access them and form object and initialize the cellTable and pass object into it ? Is it a good idea to add widgets in view's panels in presenter ?

3. Everywhere I read that reason for adding logic to presenter instead of view is to increase jUnit test coverage,which saves time. But, as far as I can see, we can use mocking frameworks on View as well to write test cases for basic logic inside them.

4. Considering point 3, does it really make sense to write so much of code(getters/ setters) in view. I believe that flow should go back to presenter from view, only when :

   a. we need to switch views

   b. we don't have data to be shown in view, so presenter can provide it via RPC

Answer 1

For starters, please see the Demystifying MVP and EventBus in GWT ( slides ) presentation from Google IO 2013. It's an update to the whole MVP + GWT approach which should answer some of your doubts and questions.

Generally, there are many opinions and approaches when it comes to MVP and designing the architecture of your application. So, YMMV.

1. I'd ask myself - is this a change to the state of data? Or just an update to the presentation? In the latter case, I'd keep it in the view, otherwise the view's interface would get unnecessarily bloated.
2. In this case, you might want to looking into creating an Editor . Then you'd use the editor's interface for editing and flushing the data - you wouldn't have to expose all the separate fields.
3. That's true - see the presentation above, where it's mentioned that in some cases separating view and presenter doesn't make sense. Especially when we have tools such as gwtmockito.
4. This depends on how you treat your views - are they dumb views, that don't contain logic and are controlled by presenters? On one hand, this makes for a nice separation, on the other, as you mentioned, the view's interface tend to get very verbose. I try to aim for the sweet-spot between this two approaches, but it really depends on your coding style and use cases.