I went round and round about this one myself, but ultimately came to the conclusion that you ether want a generalized representation of the model that you pass to the view, or have the the presenter pass in an interface to the view that is used when the view is ready to populate some widget with data. If I understand him correctly, the generalized model is similar to what Jocke pointed out. The callback interface, on the other hand, simplifies the view, but it tends to lead to cases where the presenter has intrinsic knowledge of how the view is laying out data, and to some extent what controls are being used.
You can add layers of abstraction to solve the problem, but at some point you have to realize that you *may* be making things harder to maintain. On Tue, Jan 5, 2010 at 4:43 AM, jocke eriksson <[email protected]> wrote: > I think a better solution would be setModel(TableModel model) where > TableModel is an iterface, like the Swing TableModel. This way you will have > a table that can display all sorts of domain objects. > > 2010/1/5 Benju <[email protected]> > > On the GWT wiki there is a new article (http://code.google.com/ >> webtoolkit/doc/latest/tutorial/mvp-architecture.html<http://code.google.com/webtoolkit/doc/latest/tutorial/mvp-architecture.html>) >> with good >> example of how MVP code "should" work. I found the following quote >> interesting... >> >> "Method setData() is a simple way of getting model data into the view >> without the view having intrinsic knowledge of the model itself" >> >> In the example there is only one column of date in the contacts table/ >> list which meant the view can draw itself based on a List<String>. >> What if the view was meant to display multiple columns a List<String> >> as seen in ContactsPresenter.fetchContactDetails would not work. >> >> I see three options... >> >> Change this to List<ContactDetails> but then the view references the >> model >> >> Create a new class like ContactDetailsRowData that is essential >> ContactDetails minus any non-viewed fields (ie: primary key). >> >> Break down each row in the table into it's own widget, this tends to >> get very messy though and seems hackish. >> >> I am currently leaning towards setting the view's data as a >> List<ContactDetails> and just making sure that the view only uses >> model data to display the user interface, it doesn't try to fire >> events like SelectionEvent<ContactDetails> but rather sticks to >> ClickHandlers and providing methods like getSelectedIndex(). >> >> Any ideas? >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-web-toolkit%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. >--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
