ActiveX and MVP: Implementation Strategies Redux

Hello Forum,

This morning we purchased Codejock's ActiveX Suite (after having given it
a trial run over the last 30 days), and just 10 hours later we have pretty
much brought up our application's Home Page (Dolphin truly is remarkable!).
 Codejock's controls flawlessly imitate all of the controls that can be found
in Microsoft Office, so in looking at our Home Page, you would think you
were looking at an MS-Outlook-in-progress!

Chris Uppal pointed us in the right direction with respect to incorporating
ActiveX into MVP, but now, after having studied the examples and bringing
up our Home Page, we have some deeper questions concerning the incorporation
of ActiveX into the MVP scheme.

1. Why does MaskedEdit show up as a descendant of AXValueConvertingControlSite,
while URLPresenter does not?  We're having trouble understanding why some
views would stand on their own, without a Presenter, whereas others are contained
in a Presenter.  It would seem that MaskedEdit _is_ an AXValueConvertingControlSite
while URLPresenter simply contains one.  Is this just a granularity issue,
where perhaps OA has decided to build up the web browser control a bit for
us?  

2. As you all know, MS Outlook has what is typically called a "shortcut bar"
on the left.  Codejock has a control called XtremeShortcutBar which duplicates
this control.  Further, MS Office has in general what are called "command
bars," which embraces both the toolbars and the menu bars, and so Codejock
has a control called XtremeCommandBars which implements these as well.  We'll
be using them instead of Dolphin's Toolbar and Menu.  Is it fair to say that
some ActiveX controls would require the full MVP implementation, while others
may require only a some part of it?  Since the XtremeShortcutBar will be
bound to underlying data (Model), by its specification allow user manipulation
(Presenter), and by its specification have a GUI interface (View), are we
correct to assume that this control would implement full MVP?  The XtremeCommandBars,
on the other hand (in fact, menus and toolbars in general), don't seem like
they should have a Model, but do seem to have a Presenter and a View.  So
are we correct to assume only partial MVP in this case?

3. Dolphin's online help, the technical paper "Twisting the Triad," and Ted
Bracht's book have all been excellent tools in understanding MVP.  But is
there a decision tree out there for determining which components of the triad
should be implemented?  Or is it an all-or-nothing affair?

Thanks very much.

Cheers,

Eric

"Eric Taylor" <[hidden email]> wrote in message
news:[hidden email]...
I've written a fair bit on this before. I know that Mikael Svane brought
together a nice summary of this, but although it can still be found in
Google, the actual site seems to have disappeared.

This might help though as it gives guidance on the options and some rules of
thumb as to when to use each:

http://groups.google.co.uk/group/comp.lang.smalltalk.dolphin/msg/0a9ab95df78181be?hl=en&

Regards

Blair

Hello Blair,

I went to the link you gave and printed the reply you gave to Ingo.  Your
answer to him is most helpful.  We're happy to know that the approach we
were taking before posting this question agrees with the approach that you,
yourself, prefer: option (3).

Just as a follow-on to that other post concerning the Codejock ActiveX error,
we are exploring the debugger in more detail to see how you got out of it
everything that you put into your reply.  And, rather serendipitously, we
just came upon the Kent Beck Debugger Approach (if I may give it that title)
described in the Ted Bracht's book.

So it would seems things are coming together rather well.  As my grandfather
would say, if we were to fall of the top of a building, we'd fall into a
new suit of clothes.

Cheers,

Eric

Test

Eric S. Taylor

Your
> answer to him is most helpful.  We're happy to know that the approach
we
> were taking before posting this question agrees with the approach that
> you,
> yourself, prefer: option (3).
>
> Just as a follow-on to that other post concerning the Codejock ActiveX
> error,
> we are exploring the debugger in more detail to see how you got out of
it
> everything that you put into your reply.  And, rather serendipitously,
we
> just came upon the Kent Beck Debugger Approach (if I may give it that
> title)
> described in the Ted Bracht's book.
>
> So it would seems things are coming together rather well.  As my
> grandfather
> would say, if we were to fall of the top of a building, we'd fall into
a later
> >> we have pretty much brought up our application's Home Page (Dolphin
> >> truly is remarkable!). Codejock's controls flawlessly imitate all
of
> >> the controls that can be found in Microsoft Office, so in looking
at
> >> our Home Page, you would think you were looking at an
> >> MS-Outlook-in-progress!
> >>
> >> Chris Uppal pointed us in the right direction with respect to
> >> incorporating ActiveX into MVP, but now, after having studied the
> >> examples and bringing up our Home Page, we have some deeper
questions perhaps
> >> OA
> >> has decided to build up the web browser control a bit for us?
> >> 2. As you all know, MS Outlook has what is typically called a
> >> "shortcut
> >> bar" on the left.  Codejock has a control called XtremeShortcutBar
> >> which
> >> duplicates this control.  Further, MS Office has in general what
are
> >> called "command bars," which embraces both the toolbars and the
menu
> >> bars,
> >> and so Codejock has a control called XtremeCommandBars which
> >> implements
> >> these as well.  We'll be using them instead of Dolphin's Toolbar
and the
> >> other hand (in fact, menus and toolbars in general), don't seem
like
> >> they
> >> should have a Model, but do seem to have a Presenter and a View.
So
> >> are
> >> we correct to assume only partial MVP in this case?
> >> 3. Dolphin's online help, the technical paper "Twisting the Triad,"
> >> and Ted Bracht's book have all been excellent tools in
understanding
> >> MVP.  But is there a decision tree out there for determining which
> >> components of the triad should be implemented?  Or is it an
> >> all-or-nothing affair?
> >>
> > I've written a fair bit on this before. I know that Mikael Svane
> > brought together a nice summary of this, but although it can still
be
> > found in Google, the actual site seems to have disappeared.
> >
> > This might help though as it gives guidance on the options and some
> > rules of thumb as to when to use each:
> >
> >
http://groups.google.co.uk/group/comp.lang.smalltalk.dolphin/msg/0a9ab
> > 95df78181be?hl=en&
> >
> > Regards
> >
> > Blair
> >

Eric,

I just wanted to add a few observations to the information you've already been
given in this and other threads.

> We're having
> trouble understanding why some
> views would stand on their own, without a Presenter, whereas others are
> contained in a Presenter.

One of the distinctions between View classes (as opposed to View /resources/)
and Presenter classes is that Views tend to be very generic, often not even
restricted to one domain.  Presenter classes tend to be either very simple
(like TextPresenter) or to be application-specific, or (at most)
domain-specific.

Another pattern that occurs far more often than not is that you don't get
clever Presenters hooked up to clever Views.  Either the Presenter is
pretty dumb, and is hooked up to a clever View (e.g. ListPresenter vs.
ListView), or the Presenter has complicated application-specific logic, but is
hooked up to something as trivial as a ContainerView.  (One sense in which a
ContainerView is "trivial" is that it makes no use of its Model).

A last observation, which may not leap out at you on first glance at the
architecture, is that Views are capable of acting as their own Presenters (they
implement the right protocol, etc).  If you don't specify a Presenter then the
View will be hooked up to act as its own Presenter.  That is used a lot for
things like menus, buttons, and static text, where a separately implemented
Presenter would not add much value.   Views are always used in that
configuration in the View Composer.


> Since the XtremeShortcutBar will be
> bound to underlying data (Model), by its specification allow user
> manipulation (Presenter), and by its specification have a GUI interface
> (View), are we
> correct to assume that this control would implement full MVP?  The
> XtremeCommandBars, on the other hand (in fact, menus and toolbars in
> general), don't seem like
> they should have a Model, but do seem to have a Presenter and a View.  So
> are we correct to assume only partial MVP in this case?

That's probably a case where you wouldn't bother with a special Model or
Presenter.

You may also find it, um, challenging to slot into the command framework.  That
framework is a good deal more subtle (and complicated) than it looks.  The code
is also rather confusing since there are (for historical reasons) rather a
large number of classes (and roles) with similar names.  If you are just
creating view resources, and setting Symbol commands, then you don't have to
think about the power lurking beneath the surface (and maybe not even realise
it's there), but if you are looking at the code then you have to understand
more of what's going on.  The following is /very/ approximate, but it should
give some flavour of the subtlety of the system.

The interpretation of commands is governed by a Chain of Command pattern.  In
fact it uses /two/ C-of-C patterns.

The first involves the various Views, Presenters, and (optionally) Models,
working outwards from the current focus,  to /build/ a C-of-C chain (called the
"command route").  Typically, but not necessarily, that route is just the
Presenters and Views found in the first pass.  The Model(s) can be included too
if they implement the <commandTarget> protocol.

Then that command route is used in a second C-of-C pass to find something which
is willing to implement the command (this is when your #queryCommand: methods
are called).  One nice feature is that the command itself can be added to the
route (at the head of the route), which allows one to implement "stand-alone"
commands that none of the Views or Presenters know about, but which just work
by themselves.

Lastly, the Chosen One is asked to implement the command -- but that's simple.

    -- chris

Chris,

Thank you for your contribution to Blair's response.  So much to
consider...

I've printed out your response; I may have to revisit some of these
things as I progress.  Our strategy for XtremeCommandBars, then, is this
(yes, I'm thinking out loud):

1. Establish a branded abstraction layer for Menu, say ETMenu;
2. Do the same for MenuItem;
3. Decide on the architecture of the XtremeCommandBars ActiveX control
(using your response and Blair's as a cursor);
4. Incorporate branded concrete classes into the branded abstraction
scheme above;
5. Determine a means to connect the selection of menu commands to
Dolphin's command-routing scheme.

I think the notion of dumb components, as you say, is certainly
applicable here.  The XtremeCommandBars ActiveX control is quite
intelligent.  It truly does do everything.  Concerning externalities
surrounding the control, a minimalist approach might be best, although
#5 above might become the tail that wags the dog here, as you imply.

With regards to #3, I do see a _bit_ of a model.  XtremeCommandBars
doesn't itself implement an MRU (Most Recently Used) list, a common
feature in application menus.  This is something that developers have to
layer on, although it's certainly trivial.  Also, XtremeCommandBars
comes with the ability to save down and persist the command bars layout
(an .xcb file).  I see where the MRU and a reference to the layout file
could be part of a model.

I do hope OA takes your advice of considering an abstraction layer in
the Menu hierarchies.  Indeed, there should be a layer of abstraction
between all OS-specific widgets and the OS.  My little complaint
notwithstanding, I think they did it right, though: start with the
concrete, and then refactor upwards.

Cheers,

Eric