The View Class and the #view Method: What's the Difference to MVP?

Hello Forum,

We're getting pretty comfortable with certain aspects of MVP, but we're confused
as to the difference between a view embedded in a Presenter and a subclass
of View.

For example, when we created the Home Page View for our application by selecting
the application's Presenter and choosing "New..." from the context menu,
we expected a this view to automatically show up as a subclass of the View
class.  It does not, however.  Is this because of the switch to resource-driven
views in D6?  Why are some views listed separately under View, while others
are strictly embedded in a Presenter and returned with #view?

Cheers,

Eric

Eric ,
 
You are not alone; this confuses many people.
 
Let me start by asking why you might expect every view to be
implemented as a subclass of View? To our minds, each class should
represent new *behaviour* being added to the system. If, for example,
we have a Person class then it would not seem appropriate to have
subclasses of Person for AndyBowerPerson, BlairMcGlashanPerson etc
(i.e. there is no change in behaviour, only a change in the name which
can be better represented as instance data).
 
Following this idea, when you create a new view that is a TextEdit
field and just customise it by changing (say) the background color, you
wouldn't expect this to create a new subclass of TextEdit. Rather, you
might want some way of saving down such a configured view such that it
could be restored later; this is what "resources" are -- saved down
instances of views that have been configured in some way. This also
applies to composite views that are created out of several other views.
We don't consider these to warrant their own View subclasses because,
still, no new behaviour has been added. So, this is what is the View
Composer does -- it creates instances of views and allows them to be
composed and configured and saved down as a view "resources".
 
The only time you might expect to create a new View subclass is if you
need to implement new behaviour in order to display either some new
model data or to perhaps display some existing model but in a new way.
Basically, I would only expect to implement a new View subclass if I
thought I couldn't create the view that I wanted by composition and
configuration using the View Composer. Perhaps the rule of thumb is
this: think about how you might create your view using the View
Composer and the existing view components and, if you find you can't do
it, that's a pretty good indication that you need to create a new
subclass of View instead.
 
Does this help?
 
BTW, Dolphin has always had "resource-driven" views, even prior to D6.
The difference in D6 is that the view resources are now stored down in
methods containing literal arrays (previously, there were in a sort of
black box binary STB format). The advantage of the new scheme is that
the methods contain any class names and symbol names used by the view
resource and these are visible to the compiler and hence available for
refactoring by the Refactoring Browser. In D5 and earlier, if you had
renamed a View subclass and then tried to open a view resource
containing it, this would have given an error. Now with the new scheme
the class name would be automatically renamed within the resource as
well.
 
Best regards,
 
--
Andy Bower
Dolphin Support
www.object-arts.com

Hello Andy,

>Let me start by asking why you might expect every view to be implemented
as a subclass of View?

I suppose my expectation follows from my [faulty] understanding of the MVP
paradigm, which, at least on first read, appears to be a composition of three
_separate_ elements.  For every MVP component, one is led to believe that
one would find a subclass of Model, a subclass of View, and a subclass of
Presenter.  I'm relieved by your example highlighting the difference between
instance and behavior.  Indeed, I would have been distressed by the need
to create a separate subclass of View for every variation of _instance_,
as this would contradict O-O design principles.  

The distinction, within the context of MVP, is clear to me now and, yes,
your explanation was most helpful.

Did you happen to see our other post: "ActiveX and MVP: Implementation Strategies
Redux"?  We're having the same kind of confusion with Presenters.

Thanks very much.

Cheers,

Eric