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%2bunsubscr...@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%2bunsubscr...@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.
