I don't like having two presenters either. I'm not quite sure that's what's required. My presenters have an adapter parameter, so one presenter can be coupled with different views depending on what adapter is selected. Then, depending if it's a listAdapter, editAdapter, displayAdapter, the same DTO is given to the appropriate view to display itself.
The big benefits of presenter design really revolve around fast tests. That was clearly a design choice. On the other hand, if you take a look at the new Roo and GWT 2.1 integration, I think the waters get muddled as I *think* they advertise not needing all the layering and the approach not being a pure MVP from what I understand. So it doesn't seem like a hard fast rule, but I've found the pattern very useful and it greatly simplified my development. There is only one method that does important things in my presenter (not taking into account refactoring methods out of course). So if logic breaks, I know where it is and I have fast unit tests for it. Everything else is declarative boiler plate. On Jun 2, 1:43 pm, nogridbag <[email protected]> wrote: > Mainly because of habit - I always try to avoid mixing UI related code > with client/server code. IMHO, it seems similar to doing RPC calls in > a controller or view in MVC which I think is a big no-no. > > Sticking with the article example, let's say you have two places where > you want to display contacts. The data is the same, but the views may > be completely different and thus you may want different presenters. > > So now you have: > ContactsModel > ContactsPresenter > ContactsView > > ContactsPresenter2 > ContactsView2 > > You already have the RPC call to load and initialize the ContactsModel > in ContactsPresenter. Do you simply duplicate this in > ContactsPresenter2 or does ContactsPresenter2 have a dependency on > ContactsPresenter? > > Anyway, I'm really just thinking out loud here ;) I haven't sat down > and coded any thing with MVP yet. If this is the accepted practice I > will probably do it this way too. > > On Jun 2, 1:08 pm, Tristan <[email protected]> wrote: > > > > > @nogridbag > > > What are your reasons for not having the presenter make RPC requests? > > The RPC Service is not a presenter itself. Probably the MVP model > > should be called MVPSE (services, event bus) because that's what it > > takes to make it really work. > > > On Jun 1, 4:04 pm, jocke eriksson <[email protected]> wrote: > > > > I will answer my own question here, yes I am !! Thank god for the power of > > > google. > > > > 2010/6/1 jocke eriksson <[email protected]> > > > > > Am I stupid or isn't EventBus an implementation of observer/observable. > > > > > 2010/6/1 Sripathi Krishnan <[email protected]> > > > > > There are a few things that you should keep in mind before you try to > > > >> understand the MVP pattern > > > > >> 1. You don't have reflection or observer/observable pattern on the > > > >> client side. > > > >> 2. Views depend on DOM and GWT UI Libraries, and are difficult to > > > >> mock/emulate in a pure java test case > > > > >> Now, to answer some of your questions > > > > >> *1. Why should model just be POJO's?* > > > >> - Models are shared by the server and client. If models contain code to > > > >> make RPC calls, it won't work on the server side. > > > >> - Say the models make RPC calls and update themselves. How will the > > > >> views > > > >> know about this? Remember, there is no observer/observable pattern on > > > >> the > > > >> UI. > > > >> - The only way multiple views can stay in sync is by listening to > > > >> events. > > > >> And events carry the model objects around, so everybody stays in sync. > > > > >> *2. You would have multiple presenters and one of them would > > > >> arbitrarily > > > >> have the RPC logic to initialize the model?* > > > >> Have a central, command style RPC mechanism. When the data comes from > > > >> the > > > >> server, you put it on the event bus so that every view gets the updated > > > >> data. If there is an error, you have a plug to do central error > > > >> handling. > > > >> You can also cache results centrally instead of hitting the server > > > >> every > > > >> time. > > > > >> *3. Multiple views for the same model?* > > > >> Its actually a very common thing. Say your model is a list of > > > >> contacts. In > > > >> gmail, the chat view needs this model. Also, the compose email view > > > >> needs it > > > >> to auto-complete the addresses. These views cannot "observe" the list > > > >> fof > > > >> contacts, so the only way for them to stay in sync is via events. > > > > >> *4. Why is it a poor design decision to let the view know about this > > > >> model?* > > > >> Because then your views are no longer dumb. And if they are not dumb, > > > >> you'd have to test them, which we know is difficult to do via java. > > > > >> If the view knows about the model, you will also be tempted to "read > > > >> from > > > >> the text box and populate the model". At some point, you would be > > > >> tempted to > > > >> add the validation in the view. And then there will be error handling. > > > >> And > > > >> slowly and surely, you have reached a stage where you cannot test your > > > >> app > > > >> easily. > > > > >> Which is why you want the view to only listen to low level browser > > > >> events > > > >> like clicks and key events, and then convert them to your apps > > > >> vocabulary > > > >> and then call the Presenter. Since Presenter is the only one which has > > > >> any > > > >> real code, and since it does not depend on the DOM, you can test them > > > >> using > > > >> only JUnit. > > > > >> *5. Event Handling* > > > >> That part doesn't have to do with MVP, its purely a performance > > > >> optimization. For general concepts on the subject, you may want to > > > >> read this > > > >> quirks mode article <http://www.quirksmode.org/js/events_order.html>. > > > > >> --Sri > > > > >> On 1 June 2010 23:08, nogridbag <[email protected]> wrote: > > > > >>> 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]<google-web-toolkit%2Bunsubs > > > >>> [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%2Bunsubs > > > >> [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.
