Doubts in implementing MVP

[Qrunk]

Hi,

I was reading through one of the earlier post and was unable to understand the following lines :

	Gal Dolber	Post reply 12/07/2010
	There no right or wrong way to implement MVP, its just a pattern and you can implement it as you like. The only points I think are important are: (As I already said) The view interface shouldn't have getters. This makes mocking easy peasy. (Cant I have getSaveButton() in the interface ???) Do not handle Widgets on the presenter (any widget code makes your presenter no longer testeable). This means that the methods on the ViewHandlers shouldn't have widget type parameters (What does he mean when he says Do not handle Widgets on the presenter ) Do not abuse of Event bus, at least I try no to do it.. in general if you need to notice one presenter only of an event find the way to get a reference to it. Try to use eventbus only when you need more than one presenters to handle that event.

Thanks

[Thomas Broyer]

On Sunday, January 15, 2012 11:58:43 AM UTC+1, Qrunk wrote:

Hi,

I was reading through one of the earlier post and was unable to understand the following lines :

	Gal Dolber	Post reply 12/07/2010
	There no right or wrong way to implement MVP, its just a pattern and you can implement it as you like. The only points I think are important are: (As I already said) The view interface shouldn't have getters. This makes mocking easy peasy. (Cant I have getSaveButton() in the interface ???)

What type would it be? If you're thinking about Button, then see below. If you're thinking about HasClickHandlers then you'll quickly see what Gal meant by "this makes mocking easy peasy": mocking HasXxxHandlers is a PITA, you'd better avoid it.

See also http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html

Do not handle Widgets on the presenter (any widget code makes your presenter no longer testeable). This means that the methods on the ViewHandlers shouldn't have widget type parameters (What does he mean when he says Do not handle Widgets on the presenter )

He meant "methods should not have widget types as parameters".

[Qrunk]

Hi Thomas,

As you asked, I went through the link(http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html)
but there it was a bit difficult for me to understand the basic reason as to why

1. we shouldn't use view.getSaveButton().addClickHandler().... i.e to say why we should not have getter in our Display interface?? . What I understood from the video is that it is not a good practice to maintain views state information within the presentation, but sorry to say I didn't understood how is that gonna help us. ?

2. In that video its also mentioned that we should use setListeners() rather than addListeners(), that is to avoid more than one listener in the interface.

3. He says he is diverging from Rays understanding of MVP, with respect to not using HasClickHandlers() , please explain why ?  


One of the reason why I couldnt understand the point could be that in that video there is lot of  Google Wave specific code, It would had been easier for me to understand had he used a more generic and a more simpler code to make us understand his point.

Please pardon me if I have offended any one.


Thanks

[Thomas Broyer]

On Monday, January 16, 2012 4:05:01 AM UTC+1, Qrunk wrote:

Hi Thomas,

As you asked, I went through the link(http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html)
but there it was a bit difficult for me to understand the basic reason as to why

1. we shouldn't use view.getSaveButton().addClickHandler().... i.e to say why we should not have getter in our Display interface??

If you want to test your presenter, you'll create a mock view. With a getSaveButton, you have to mock a HasClickHandlers in addition to the view. The mock will record the added ClickHandler-s, and should return HandlerRegistration to allow unregistering them. Finally, to simulate a click, you might need to mock a ClickEvent too (you could pass 'null' as the event if you know the presenter isn't going to extract any information from the event). This is a lot of boilerplate for a single button.

If you instead have a onSave() or save() or doSave() on your Presenter interface (that the view calls back), mocking the view and simulating the "click" becomes much easier.

 

What I understood from the video is that it is not a good practice to maintain views state information within the presentation, but sorry to say I didn't understood how is that gonna help us. ?

This is another aspect of how Wave implemented MVP: the presenter maintains the state, and pushes it to the view; not the other way around. Again, this makes mocking and testing easier. For instance, instead of having your values "stored" in your view's fields (TextBox for instance), you'll store them in (Java) fields in the presenter. You'll push the value to the view each time you detect it changes, and the view will pass it back to the presenter as an argument to the callback method.

This doesn't work very well with data-heavy screens (e.g. when you have half a dozen form fields or more) though, but it works very well with small reusable widgets (Wave uses it for buttons for instance, where their buttons' views are not simply Button widgets, and where the "state" stored in the presenter is whether the button is enabled/disabled, its text, whether it's pressed/released)

 

2. In that video its also mentioned that we should use setListeners() rather than addListeners(), that is to avoid more than one listener in the interface.

Again, makes things simpler; and you'll actually never have 2 listeners (2 presenters) at the same time, so.

 

3. He says he is diverging from Rays understanding of MVP, with respect to not using HasClickHandlers() , please explain why ?

See above.