Hi, I've been reading the articles on MVP recently, specifically the articles here:
http://code.google.com/webtoolkit/articles/mvp-architecture.html http://code.google.com/webtoolkit/articles/mvp-architecture-2.html I've primarily worked with MVC in the past so this is my first exposure to MVP (I've of course heard about it before but never really cared to learn about it in depth). Here's a few things that I wanted to comment on to perhaps help me understand this all better. 1. Everyone does MVC slightly differently, but I've always treated the model as more than a simple data object. In MVC, I've always designed it so that it's the model's responsibility to do RPC calls - not the controller. In MVP, I noticed you suggest to put this logic in the presenter. It seems a little strange to me. What if you want multiple views to essentially be an observer of the same model (I know I'm speaking in MVC terms but you get the idea). You would have multiple presenters and one of them would arbitrarily have the RPC logic to initialize the model? I know in practice there's very few times in which you actually need to have multiple views for the same model - so I'm OK with this decision. Just an observation... 2. If the model is simply a DTO as you suggest, why is it a poor design decision to let the view know about this model? DTO's are simple POJOs with no logic. True, the view will become arguably a little smarter. But from a maintainability standpoint I don't see why simply moving this to a third party class, ColumnDefinition, would make it easier to maintain. Whenever more abstraction is added, the code is typically much more complicated, difficult to read and understand the flow, etc. When I look at that ContactsViewImpl with all the generics everywhere, I cringe a little bit. Honestly, I don't have much experience with unit testing UI. So maybe in a few sentences can you explain why having the view have a dependency on the model (a simple pojo) will make testing more difficult? 3. My final comment is about sinking the events. The article states: "Reduce the event overhead by sinking events on the HTML widget, rather than the individual cells." In the code, I was expecting to see a single DOM.sinkEvents... but instead it looks like each individual cell sinks events: for row for col // TODO: Really total hack! There's gotta be a better way... Element child = cell.getFirstChildElement(); if (child != null) { Event.sinkEvents(child, Event.ONFOCUS | Event.ONBLUR); } Is this a mistake? Or by "sinking events on the widget" you mean sinking several events on a single widget is better than sinking events on several widgets? Thanks! -- 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.
