On Tuesday, September 27, 2011 2:45:20 AM UTC+2, Behi wrote: > > Thanks for the response. I shall have a look at those links later > tonight. > > > If you value theory and "purity" more than pragmatism and productivity, > then > > yes, it probably violates the pattern, as it doesn't use the observer > > pattern. > > My concern is not that passing the presenter to the view is a bad > thing per se, but that when doing so we can not say we have > implemented the MVP pattern anymore, as in each design pattern the > collaborators, their responsibilities, and the relationships between > them are set in stone so that when I say that Foo is Singleton it is > universally clear what Foo is. In other words, design patterns make it > possible to communicate ideas clearly as long as they have a clear and > universal definition. > > So maybe we should call this design pattern something else. However > looks like there's not a clear definition of MVP available anyway, as > for example in Dolphin Smalltalk it means something different to > ASP.NET. >
Exactly, there's actually no "MVP" pattern. The agreed-upon definition of MVP is that you have M↔P↔V, vs. the M→V→C→M triangle of MVC (which is not to be confused with the "web MVC" pattern popularized by Ruby on Rails and used in ASP.NET). > Now back to passing the Presenter to the View, what methods of the > presenter should be exposed to the view? Should the view still be > ignorant about the model? or should we expose > PresenterImpl.getContacts(): ArrayList<Contact> to the view as well? Go read the slides I linked to earlier ;-) I didn't do it that way personally, but I'll try to stick with that approach from now on. Basically, all interfaces are "push-oriented": the presenter pushes data to the view and/or otherwise control how the view should appear and behave, and the view "pushes" changes to the presenter in response to user events. Of course, this is again only theory, as the use of the Editor framework and/or cell widgets (CellTable, CellList) blurs the presenter/view line and changes their interaction a bit (the editor framework is based on the Flow Synchronization pattern, whereas the above idea is a bit more like Observer Synchronization –despite not using events and observers per se–) One thing is clear (to me at least): there's absolutely no reason that your view is ignorant about the model, particularly if it makes things easier to code and maintain, and doesn't decrease testability. That being said, I'm a supporter of a "do things like you feel they best suit your needs" approach rather than "try to stick to the patterns as closely as possible", so don't take my words above for granted. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/MPgOSG2Zfi8J. 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. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
