MVP: Presenter vs. View

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

bill wrote:

> ...   how are the Presenter and the View separated in Dolphin's version of
> MVP?

A great question. To find out the answer, do the following:

1. Go to the class Presenter in the browser, and select the method #view.
2. Browse all "local references to #view".
3. See which particular methods are sent from these references to the
    result of #view. Now you know how Presenter depends on View.

4. Go to the class View  and do the same operations for method #presenter.
    Now you know how View depends on Presenter.

This works provided no methods are sent directly to the instance
variables. Interestingly there seems to be quite a few calls.
In subclasses probably more.

A better design might be one that defined 'role objects'. The
Presenter would  store in its instance variable a PresentersView
that only provided of subset of  View's methods meant for the
Presenter. And vice versa. That would make it clearer what the
interfaces in fact are.

But perhaps someone with better knowledge of Dolphin can give
a better answer.

-Panu Viljamaa
--
P.S. For an approach for defining interfaces in Smalltalk, see:
http://members.fcc.net/panu/SmalltalkTypes.htm

Bill,

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

There is an intimate interaction between the Presenter and View. These two
are not loosely coupled but, in fact, rather tightly coupled. That does not
make the separation any less useful, though. Views are *pluggable* display
devices (Bruno, likens them to "skins" in another reply which, I think is a
good way to think of them).

Presenters represent the majority of your application UI logic. When you
create a UI you build a presenter (either a simple one or as a composite of
others) and this can largely be done without reference to how the UI will
actually look. When you come to add the view layer (the "skin") you most
often do so by assembling pre-existing view instances using the View
Composer (*) and these get plugged on to the presenter when the triad is
initialised.

(*) The exception to this is when creating a simple MVP component where you
don't have a suitable view class to display the data in the model. Then
you'll need to create a new class to add the behaviour necessary to paint
the model data in a window (see ScribbleView).

I don't think either of these is true (see above). Think of it in terms of
responsibilities:

1) The view is reponsible for displaying the model data.
2) The presenter does everything else associated with the UI. It gets user
gestures (selections, commands, clicks etc) from the view and determines how
these are used to make the user interact with the model data.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Andy,

> > 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?
>
> I don't think either of these is true (see above). Think of it in terms of
> responsibilities:
>
> 1) The view is reponsible for displaying the model data.
> 2) The presenter does everything else associated with the UI. It gets user
> gestures (selections, commands, clicks etc) from the view and determines
how
> these are used to make the user interact with the model data.

What about interactors?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Andy Bower wrote:

> ... There is an intimate interaction between the Presenter and View. These two
>
> are not loosely coupled but, in fact, rather tightly coupled. That does not
> make the separation any less useful, though. Views are *pluggable* display
> devices (Bruno, likens them to "skins" in another reply which, I think is a
> good way to think of them).

Isn't it the case that the less coupling there is, the easier
it becomes to 'plug' things together?

If the coupling is very tight, it becomes hard to devise
a new component from scratch, without intimately knowing
the details of this coupling. And even when subclassing,
it becomes hard to know what could or should be redefined
in a subclass, without breaking inherited things in subtle ways.

This is not not to disparage MVP, but just a thought.
I believe the thrust  of the original question is:

    Wouldn't MVP be even better if we could reduce
    the coupling between V and P?

The answer may be "No", or "It is not feasible to do so".
ButI think it is a good question still.

-Panu Viljamaa

--
http://members.fcc.net/panu/SmalltalkTypes.htm

Panu,

> > ... There is an intimate interaction between the Presenter and View.
These two
> >
> > are not loosely coupled but, in fact, rather tightly coupled. That does
not
> > make the separation any less useful, though. Views are *pluggable*
display
> > devices (Bruno, likens them to "skins" in another reply which, I think
is a
> > good way to think of them).
>
> Isn't it the case that the less coupling there is, the easier
> it becomes to 'plug' things together?

It depends what you mean by coupling. In this case I was implying that both
the presenter and view have instance variables that point to the other one
of the pair. I would call an Observer relationship loosely coupled.

> If the coupling is very tight, it becomes hard to devise
> a new component from scratch, without intimately knowing
> the details of this coupling. And even when subclassing,
> it becomes hard to know what could or should be redefined
> in a subclass, without breaking inherited things in subtle ways.

In this case the "coupling" between presenter and view is fairly loose. A
list presenter has to know that the view it connects with is capable of
displaying lists but not much else. You'll find that a number of protocols
have been set up to define the interfaces that various views and presenters
implement( e.g. listView and listPresenter). The set is by no means complete
and more work could be put in to documenting the interdependencies in this
way if required. Any takers?

> This is not not to disparage MVP, but just a thought.
> I believe the thrust  of the original question is:
>
>     Wouldn't MVP be even better if we could reduce
>     the coupling between V and P?

The answer would be yes. Whether it is feasible without a major redesign, I
don't know. The first stage would be to isolate areas where it is perceived
that the interdependency in the existing MVP implementation is too great and
causes problems.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Bill,

> What about interactors?

Interactors are a more advanced feature that most people don't need to worry
about. The idea is to convert low level user gestures (mouse clicks,
movements etc) into higher level ones. Most of the time the Windows controls
can be assumed to have their own built-in interactors. For example, a
windows text editor automatically handles keydown/keyup pairs and turns them
into WM_CHAR (#onKeyTyped:) events. For this reason the default interactor
for any view is itself.

Sometimes, however, it is desirable to abstract some lower level events into
something at a higher level. In these cases it is possible to install an
interactor other than the view itself. The only explicit interactor in the
base Dolphin system is MouseTracker. From the class comment:

<MouseTracker> is an <Interactor> that is used to manage the visual dragging
of objects using the mouse. An instance should be created as the result of a
mouse down event and once started using #startTracking: it captures the
mouse and relays the drag messages that are part of the <mouseTrackerTarget>
protocol to the target that is assigned to it. Once the drag has completed,
and the originating button has been released, the mouse capture is also
dropped. Tracking will also be cancelled if the user Alt+Tab's to another
application, or presses the ESC (escape) key (assuming the originating view
still has focus).

So this interactor takes a number of low level mouse events and turns them
into a series of messages that a presenter (typically) can use to process
dragging. Take a look at how it installs itself in MouseTracker>>setCapture.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---