I've read two articles on MVP: "Twisting the Triad" by Bower and
McGlashan of Object Arts (cited by Dave Harris in an earlier post: (http://www.object-arts.com/Papers/TwistingTheTriad.PDF), and "MVP: Model-View-Presenter: The Taligent Programming Model for C++ and Java" by Mike Potel of Taligent(/IBM?) (http://www-106.ibm.com/developerworks/library/mvp.html). The separations between Model and Presenter and between Model and View are quite clear in my mind: the Model knows nothing about the Presenter and the View; it only provides hooks for them via its API and, in particular, its ability to register and notify observers/listeners. But, after reading the papers above, it is still not clear to me exactly how the Presenter and the View are separated. There seems to be a rather intimate interaction between the two in that each has to know quite specific details about the other. I still can't see how these two components are "separated" in any meaningful way. I can think of two ways in which the Presenter and the View could be separated. One is that either the Presenter observes the View (just like the View observes the Model), or vice versa. The second way is to define very small interfaces for either the Presenter or the View or (preferably) both. This ensures a weak coupling between the actual Presenter and the View classes. (I'm more familiar with the technique of defining interfaces in Java than in Smalltalk, so this approach may or may not be relevant in the context Smalltalk). Does Dolphin MVP use either of these general approaches? If not, how are the Presenter and the View separated in Dolphin's version of MVP? Thanks! bill |
Hi,
A Presenter can have more than one view !!!. A View is one skin of a Presenter ! Best Regards Bruno |
[hidden email] (Bruno) wrote (abridged):
> A Presenter can have more than one view !!!. Do you mean that the Presenter's single View may be a composite View, with sub-Views? > A View is one skin of a Presenter ! I think if I were writing a multi-skin UI, I'd make a kind of composite View in which only one sub-View is visible at a time. The trouble with true multi-View Presenters is that when a View sends the Presenter a message, the Presenter has to figure out which View it came from. We could cope by using adaptors, but I thought part of the beauty of MVP is that it avoided that particular complication. Dave Harris, Nottingham, UK | "Weave a circle round him thrice, [hidden email] | And close your eyes with holy dread, | For he on honey dew hath fed http://www.bhresearch.co.uk/ | And drunk the milk of Paradise." |
"Dave Harris" <[hidden email]> escribió en el mensaje
news:[hidden email]... > [hidden email] (Bruno) wrote (abridged): > > A Presenter can have more than one view !!!. > > Do you mean that the Presenter's single View may be a composite View, with > sub-Views? No. I mean a Presenter with a default view and another views to use it. For aPresenter you can make more tha one View. Of course, it depend on your application. I use it when I have an application with a lot of user kind. For some kind of user you can have differents Views for the same Presenter. Take a look at: MethodBrowser views or ClassBrowserShell views. The Presenter's behaviour should be the same for each view (but it depends on what you want). Best Regards Bruno Brasesco |
[hidden email] (Bruno) wrote (abridged):
> > > A Presenter can have more than one view !!!. > > > > Do you mean that the Presenter's single View may be a composite View, > > with sub-Views? > > No. I mean a Presenter with a default view and another views to use it. Oh, right. You mean different views at different times, though still only one at any given time. Pluggable views. OK. I misunderstood. Dave Harris, Nottingham, UK | "Weave a circle round him thrice, [hidden email] | And close your eyes with holy dread, | For he on honey dew hath fed http://www.bhresearch.co.uk/ | And drunk the milk of Paradise." |
Free forum by Nabble | Edit this page |