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%[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.
