GWT & MVP - Best practices for displaying/editing complex objects?

Question

All the GWT / MVP examples I've learned about seem too simplistic to give a clear view what best practises are regarding displaying and handling slightly more complex model objects.

For example, most examples are something like a presenter that attaches a click handler to a few TextBoxes on the view...if save is clicked, the presenter's save() is called which simply gets the updated values, and we're done, MVP style. That's not so realistic though.

For example, let's say we have:

PresenterX - gets a 'model' object, let's say any object with an unknown number of various primitives or whatever

ViewX - should show the model object in a table, and/or allows it to be edited/re-saved

...so that sounds very, very basic. But, we don't know the amount of fields in the model object that we will need to display. So that might relate to a dynamic number of rows/columns. Probably no problem for a table...but how should the presenter give this to the view's table? As the model object that the view understands, or break it down into a bunch of Lists...that the view essentially still has to understand.

Also, certain fields might be editable, of which are unknown until we get the model object (something in the model determines what fields are editable, say) -- so who should be responsible for figuring out what is editable or not? Probably the presenter, but how do we refelct that in the view, the MVP way?

Lastly, let's say there's a 'save' button on the view...who's job is it to figure out all the rows in the table which were changed?

Seems to me that the view either needs to understand the model more, or the presenter needs to really understand the view more -- neither of which are nice MVP :( ... Or perhaps there should be some intermediary object.

I know there are some nicer/newer helpful ways for this kind of stuff (Editors/RequestFactory, etc.), but I'm looking for suggestions on the above scenarious.

Answer 1

As I understand it, MVP is a line with M-P-V points. So P interacts with both, but M and V only with P.

Also, one of design objectives of MVP is to have a testable P and M, which means that V must be replaceable with a mock version. So, V should not expose any implementation-dependent interfaces (e.g. HasClickHandlers instead of Button).

Now, if V should show generic table, you should create generic methods: addColumn(..) to define columns and addRow(..) to add data. The new CellTable is pretty flexible and supports adding columns dynamically.

About changes - V should notify, P should act. Also, there are the new Editors, which IMHO do not fit nicely into MVP, but are supposed to be easy to use.