On Tuesday, January 8, 2013 3:52:32 PM UTC+1, MAQ wrote:
>
> 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?
>
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.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/O6VEBPBh3XEJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
