MVP View vs. Presenter?

I have been through the tutorials but still can't seem to grasp the
distinctions between View and Presenter.  Nor between "Views as
subclasses of the View class" and "Views as resources attached to
Presenter classes".

Does anyone have some words of wisdom for me?

Thanks,
John

John,

> I have been through the tutorials but still can't seem to grasp the
> distinctions between View and Presenter.

Views do the grunt work of displaying data to the user.  Dolphin uses native
Windows widgets where possible, but, you can create your own View subclasses
to render data in any way you find necessary.  At a lower level, views are
involved with handling Windows messages, but, that's usually transparent
unless you want to handle messages not already mapped in Dolphin; there's an
article on the Wiki that you'll want to read should you need to venture into
this area.

Presenters mostly tie things together.  Most of the event handling that
you'll do (perhaps handling a left button click or selecting from a list
box) will be done in presenters.  A typical composite presenter observes
events fired by its subpresenters to coordinate activities of the
subpresenters.  You might watch for a change in selection of a list to
update the contents of a text presenter; all of this can be done with
trigger wiring in your presenter rather than by subclassing the list box and
edit control.


> Nor between "Views as
> subclasses of the View class" and "Views as resources attached to
> Presenter classes".

A "View resource" is basically just byte arrays containing an STB-filed
Prototype instance.  It works like this: when you edit a view in the view
composer, you are manipulating a live instance of the view.  When you save
the view as a resource, the VC binary files the view into a byte array.  The
View sub-instance responds by saving an STBViewProxy that knows how to
reconstruct the view by creating a new window and then changing attibutes to
make it look and act like the one you edited.

So, view resources are "dehydrated" views: just add water :)   As far as
subclasses of View, the truth is that not all views need to be subclassed
from View, though I would think it **highly** unlikely that you'd ever want
to create your own view system.  The one outstanding exception to this would
be a possible port of MVP to other operating systems and/or Smalltalks;
otherwise, the existing Dolphin view resources satisfy most needs, with
subclassing View filling in the rare gaps.


> Does anyone have some words of wisdom for me?

I'm not sure if I'd go so far as to call it wisdom<g> - hopefully it helped
a little.  Any questions?

Have a good one,

Bill

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

Bill Schwab wrote:
Ok, I'm looking at the Scribble example.  There is a class Scribble
(subclass of Presenter) and a class ScribbleView (subclass of View).  I
right-click on Scribble and choose 'edit view'.  I get the view composer
titled 'Scribble.Default view(ScribbleView)'.  If I change this am I
changing the definition of the ScribbleView class? (I think not).

Or, I right-click on Scribble and choose 'new view'.  I get the View
composer and File/SaveAs 'JohnsNewScribbleResource'.  The title is now
'Scribble.JohnsNewScribbleResource(ScribbleView)'.  Hmmm.  What exactly
is it that connects this to the (ScribbleView).

Sorry, I guess I'm not really sure what I should be asking, I'll just
have to ponder this some more.  Thanks for trying to help :)

Cheers,
John

John,

> Ok, I'm looking at the Scribble example.  There is a class Scribble
> (subclass of Presenter) and a class ScribbleView (subclass of View).  I
> right-click on Scribble and choose 'edit view'.  I get the view composer
> titled 'Scribble.Default view(ScribbleView)'.  If I change this am I
> changing the definition of the ScribbleView class? (I think not).

You're thinking correctly.  In this case, you are changing the prototype
view instance that will be associated with the presenter.


> Or, I right-click on Scribble and choose 'new view'.  I get the View
> composer and File/SaveAs 'JohnsNewScribbleResource'.  The title is now
> 'Scribble.JohnsNewScribbleResource(ScribbleView)'.  Hmmm.  What exactly
> is it that connects this to the (ScribbleView).

Look at the #defaultView method; you can override this for any presenter, or
you can select the view resource to use when showing a presenter (look for
variations on #show:).

> Sorry, I guess I'm not really sure what I should be asking, I'll just
> have to ponder this some more.  Thanks for trying to help :)

This gets a lot easier; it's worth the effort to figure it out.

Have a good one,

Bill

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

John,

> > > I have been through the tutorials but still can't seem to grasp the
> > > distinctions between View and Presenter.

Have you read the original Taligent paper on MVP. It's now at:

http://www.ibm.com/java/education/mvp.html

> Ok, I'm looking at the Scribble example.  There is a class Scribble
> (subclass of Presenter) and a class ScribbleView (subclass of View).  I
> right-click on Scribble and choose 'edit view'.  I get the view composer
> titled 'Scribble.Default view(ScribbleView)'.  If I change this am I
> changing the definition of the ScribbleView class? (I think not)

No, the View Composer builds instances of views. It never modifies a view's
class. Most often this useful when combining views together to form a
composite. Sometimes it's also handy to be able to configure individual
instances of "basic" (i.e. non-composite views).

Perhaps your confusion stems from the fact that some GUI builders emit a new
class as the result of what they draw. We don't do this because (while it
can be handy for some purposes, source control for one) we generally think
it is wrong. If this is isn't what's troubling you then you can skip the
following explanation to avoid becoming even more subdued. When you are
dealing wth OO design you often have to decide when it is appropriate to
create a new class or just "configure" an instance of existing one. My rule
of thumb would be, do I need to add new behaviour, i.e. change the way an
object responds to messages or am I just changing state? In the former case
a new class is appropriate, in the latter an instance can be configued to do
the job.

You wouldn't dream of creating two classes for the strings, "Hello" and
"World" (HelloString and WorldString, say) since the only different between
them is their contents; their behaviour is the same. Hence you wouldn't
dream (I hope) of asking the View Composer to create a new subclass of
ScribbleView if you just change the background colour to orange. This sort
of configuration, which the VC engages in all the time, is best handled by
holding on to instances of views rather than by modifying classes. The
Resource Manager is effectively a repository for instances of views (albeit
ones that have been streamed out to a binary array and can be reconstructed
later).

> I right click on Scribble and choose 'new view'.  I get the View
> composer and File/SaveAs 'JohnsNewScribbleResource'.  The title is now
> 'Scribble.JohnsNewScribbleResource(ScribbleView)'.  Hmmm.  What exactly
> is it that connects this to the (ScribbleView).

The New View command says, "Hmm.. this chap wants to create a new view for
Scribble. Well whats the best starting point I can give him? I know, I'll
create a copy of the existing defaut view instance and give him that to play
with". Hence after executing that command you end up editing a copy of
"Scribble.Default view" which (obviously?) contains an instance of
ScribbleView.

Perhaps what you're missing here is that, at some point way back in the
mists of time, somebody (and I think it was me) had to create the original
instance of ScribbleView and add it to the Resource Manager. Shortly after I
wrote the ScribbleView class, I evaluated:

ScribbleView makeResource: 'Default view' inClass: Scribble.

This created an instance of ScribleView and added it to the Resource Manager
as a resource called "Default view" and associated with the Scribble
presenter. I could go into why we chose to asscociate resources with classes
but I won't right now (partly because it was probably a bad idea). Then I
think the next thing I did was to open "Scribble.Default view" in the VC and
change the background colour to yellow. It was  just a "yellow" day I guess.

Let me know if this does, or doesn't help.

Best regards,

Andy Bower
Dolphin Support
http://www.object-arts.com

---
Visit the Dolphin Smalltalk Wiki Web
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

... for your replies.  I am making pretty good progress now.  (More
specific questions will probably follow :)


Cheers,
John

Andy Bower wrote:

> Hence you wouldn't
> dream (I hope) of asking the View Composer to create a new subclass of
> ScribbleView if you just change the background colour to orange.

Correct... but I would like a class method created to store different means
of instanciating different configurations of instances of that class.  The
big problem with any instance based configuration (such as the Dolphin views
and the VW exceptions (circa 1995)) is that they are invisible to the
standard Smalltalk development paradigm... mainly the browser.

John Keenan