@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 <jock...@gmail.com> wrote: > I will answer my own question here, yes I am !! Thank god for the power of > google. > > 2010/6/1 jocke eriksson <jock...@gmail.com> > > > > > Am I stupid or isn't EventBus an implementation of observer/observable. > > > 2010/6/1 Sripathi Krishnan <sripathi.krish...@gmail.com> > > > 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 <nogrid...@gmail.com> 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 google-web-toolkit@googlegroups.com > >>> . > >>> To unsubscribe from this group, send email to > >>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs > >>> cr...@googlegroups.com> > >>> . > >>> 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 google-web-tool...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs > >> cr...@googlegroups.com> > >> . > >> 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 google-web-tool...@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.
