In MVP is there a difference between declaring the 'binding' interface in the presenter versus the view?

[MAQ]

I saw a lot of sample code, most of them use the following way of creating MVP:

public interface ContactsView<T> {

  public interface Presenter<T> {

    void onAddButtonClicked();

    void onDeleteButtonClicked();

    void onItemClicked(T clickedItem);

    void onItemSelected(T selectedItem);

  }

  

  void setPresenter(Presenter<T> presenter);

  void setColumnDefinitions(List<ColumnDefinition<T>> columnDefinitions);

  void setRowData(List<T> rowData);

  Widget asWidget();

}

Then let the presenter implement ContactsView.Presenter<Contact>. However some do the following:

public class ContactsPresenter implements Presenter {  

  public interface Display {

    HasClickHandlers getAddButton();

    HasClickHandlers getDeleteButton();

    HasClickHandlers getList();

    void setData(List<String> data);

    int getClickedRow(ClickEvent event);

    List<Integer> getSelectedRows();

    Widget asWidget();

  }

//.........................

}

Then let the view implement the ContactsPresenter.Display.

Are there any good points for doing either methods, maybe one is better suited for UiBinder?

2- Another question, is the view not suppose to directly communicate with the model at all. For instance, if I've got a ListBox that should be populated from an Enum class that sits in the model, should that be done through the presenter?

[Thomas Broyer]

See https://developers.google.com/web-toolkit/articles/mvp-architecture vs. https://developers.google.com/web-toolkit/articles/mvp-architecture-2

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

In brief: the former makes it way easier to mock the view to unit-test your presenter. And if you don't put getters in your view, the "source of truth" will be your presenter, and your view will only be considered a… view, of the same data.

2- Another question, is the view not suppose to directly communicate with the model at all. For instance, if I've got a ListBox that should be populated from an Enum class that sits in the model, should that be done through the presenter?

I don't think any purist would tell you your view shouldn't *know* about the model. What you should not do is a) pull data from the view, b) update the model from the view, or c) listen to model changes in the view; everything should go through the presenter: it holds data *to* the view, the view asks the presenter to modify the model, and the presenter possibly observes model changes and reflects them in the view.