Re: MVP:should the View object keep a reference to the corresponding Activity object?

2014-05-15 Thread ehodges
No, the view should be a simple container for UI objects.  The only 
exception should be a reference to the event bus, so UI Binder event 
methods can fire events.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: MVP:should the View object keep a reference to the corresponding Activity object?

2014-05-14 Thread Thomas Broyer

On Wednesday, May 14, 2014 11:57:34 AM UTC+2, wahaha wrote:

 should the View object keep a reference to the corresponding Activity 
 object(which act as a presenter)?
 in the demo called helloMVP provided by the gwt official site,it does.
 but in my humble opinion,Presenter is the layer on top of View.and the 
 upper layer may invocate the lower layer,but the lower layer shoudn't 
 invocate the upper layer.
 so,i think the view object shoundn't keep a reference to the activity 
 object.


It depends how you implement MVP wrt listening to events: is the presenter 
pulling widgets from the view to attache event handlers to them (or 
possibly attach them through specialized methods on the view, e.g. 
addSubmitButtonClickHandler vs. getSubmitButton().addClickHandler) or is it 
implementing a callback interface that is passed to the view (so the 
addClickHandler is done in the view, possibly through UiBinder, and simply 
delegates to the appropriate method of the presenter interface, e.g. 
presenter.onSubmitButtonClicked()).
But in any case, the view keeps one (or several) reference(s) to the 
presenter, either directly or indirectly through event handlers.

You might argue that the presenter might not directly implement the 
callback interface, but it's exactly the same, just with an additional 
level of indirection: the view (or its widgets) has to call back to the 
presenter when the user interacts with it, so it must keep a reference to 
it.
You could use an event bus to decouple things, but that's using a 
sledgehammer to crack a nut; you'll pay it in performance and 
maintainability: it's not because you split the view and the presenter that 
they're decoupled. The main reason for using MVP is to be able to mock the 
view and avoid using a GWTTestCase to test the presenter (and you can test 
it at a slightly higher level, e.g. show error on field rather than put 
error message in panel, show panel and add error style to field).

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.