Smalltalk › Usenets › Dolphin Smalltalk

Re: MVC/MVP Comparison

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

David Simmons

Re: MVC/MVP Comparison

"Richard MacDonald" <[hidden email]> wrote in message
news:ybz_6.13409$[hidden email]...

> "Andy Bower" <[hidden email]> wrote in message
> news:9hcb7m$cqq5m$[hidden email]...
> > Richard,
> >
> > > > Think of it like this. The view handles output (i.e. display of the
> > model
> > > > data). The presenter handles input (i.e. changes to the model data).
> In
> > > > general the presenter doesn't monitor events from the model but it
> does
> > > > monitor UI events from the view that say when and how the user want

> > > make
> > > > changes to the data. The presenter is not a Mediator.
> > >
> > > I still cannot feel comfortable with this. 3 objects and 3-way
> > > communication paths seems like a recipe for confusion.
> > > It prevents layering for one. For another, I
> > > worry about interpreting when a Model event is something only the View
> > > needs to deal with, or when the Model+Presenter needs to deal with it
> > > or when only the Presenter needs to deal with. Having the Presenter as
> > > Mediator gives a solution to this concern (one place to decide). 3-way
> > > communication complicates things. All I can say right now is that I
> > > implemented the Presenter-as-Mediator and I like the results. But I'm
> > > only a data point and perhaps a confused one at that.
> >
> > So, are you saying that your presenter intercepts all model event and

then
> > manipulates the view to display the changes? How does it do this? Does
it
> > call view methods directly (it is able to do) or does it retrigger the
> > events and the view hangs off these. If it is the latter, we did try
this
> > originally but it seemed too inefficient (intercepting and re-triggering
> > events). If the former then it sounds reasonable (but not the same as
> > Taligent's MVP).
>
> In a sense, the Presenter is an Adapter. Presenters and Adapters work in
> a Composite pattern, although there is obviously a separation between
them.

> "Atomic" Adapters hold onto a View widget, a Model object, and a block
> (or just a Model since I often use the Property pattern). The Model and
> View both send their events to the Adapter. The Adapter forwards in both
> directions with appropriate interpretation and conversion. The
> AtomicAdapter is a convenient place to attach formatting objects.
> Then, I create CompositeAdapters which attach to a Model and a
> Pane. These delegate out to AtomicAdapters as normal, and they also
> handle the propogation of disconnecting/reconnecting to different Models
> (e.g., for a Form editor on a list of Model objects). Panes can be nested,
> as can CompositeAdapters. Finally, this bottoms out in a Window View
> and a "top" Adapter. With this approach, there is not much you have to
> add to an Adapter to make it function as a Presenter. Opening and closing
> windows, connecting to menu events, switching between view mode and
> edit mode, persisting changes, etc. I never had serious problems with
> going "in and out" of the composite hierarchy, but I suppose this could
> be challenged in other application domains.
>
> I'll have to look at my code again (old Smalltalk, and I've put it aside

for
> a
> year as I work with strict domain programming in Java), but I basically
> called all these things Controllers and there was a natural progression
from
> widget to
> window. This worked for spreadsheet widgets too, when I sent a collection
> of Model objects to a spreadsheet "presenter/adapter". I could have used a
> CollectionWithEvent objects, though.
>
> I would also confess I abused implementation inheritance to a great
degree.
> For example, all my "WindowAdapters" inherited from an object which
> handled an OK button and a Cancel button, whether or not they actually
> had one. But with Smalltalk, it was very easy to control. Seriously
> coupled to an overall framework, but that is the price of frameworks.
>
> > The 3 way communication is not really confusing since it is generally
one

> > way traffic around the triad.
> >
> > Model -> View
> > View -> Presenter
> > Presenter -> Model
>
> *AH* I never got that. I always had problems because my Presenter
> listened to both View and Model events, so I had to ensure that the
> Presenter didn't deal with events caused by itself. This led to special
> methods like #setQuietly: in the widgets.
>
> How do you deal with something like: "Presenter tells Model to do
> something which informs View which informs Presenter the View
> has changed so Presenter . . ."
>
> > I'm not sure, but I wonder whether the triad (rather than the layered
> > approach) gives more options for pluggability. I can't think of any
> example
> > right now, however.
>
> I had great power in terms of reuse, but I suspect I was not as pluggable

> you would be.
>
> > If you remember, in "Twisting the Triad", I stated that by the time we
> came
> > to take a look at MVP we were at the ends of our tether. We'd spent far
> too
> > long evaluating widgets and MVC and didn't want to "invent" a new UI
> > framework since we didn't have the confidence to do this. The fact that
> the
> > Taligent guys had spent significant time (and plenty of IBM's cash)
> > developing MVP gave us some hope that it might be a reasonable approach.

<g> It was actually Apple's cash not IBM's. The bulk of Taligent's design,
development/R&D work was done before Apple spun out Taligent (and
subsequently sold it to IBM because the C++ development was costing too
much). Internally the project became code named "the black hole". Much of
Taligent's framework development efforts were derived from Apple's
experience with MacApp which was Larry Tesler's Object Pascal framework
carried forward from his involvement with Smalltalk at Xerox Parc. Other
portions were influenced by internal projects like SK8 and ScriptX (all of
which I was involved in, including Taligent).

Taligent came into being when Apple wanted to develop their next generation
OS -- their competitor to Windows NT. They put all their best people onto
the project (which never gave back anything to Apple since they were not
able to use it as their new OS). This was the project that really began the
Apple OS tailspin that ultimately brought us to MacOSX (ironically an
equivalent remake of A/UX).

It sapped the best and brightest from Apple and (it/c++) drained their souls
trying to build one of the most complex and sophisticated OS systems of that
period, in C++. The project probably did more to mature, solidify and make
C++ a useful (and efficiently compiled) language than any other work of that
period. Just as a true anecdote, it use to take them hours to do builds in
C++, so they had video games and other recreational facilities to bide their
time while waiting for builds to finish. It also gave them a lot of time to
think/plan/design their frameworks -- which put them on the opposite end of
the spectrum from XP.

--
-- Dave S. [ http://www.smallscript.net ]

> All
> > I can say is that we've been reasonably happy with the result. Your
> layered
> > approach may be better.
> >
> I remember your comments. Frankly, I'm thinking out loud without the hard
> facts at my disposal, and I hope I'm not sounding critical -- I'm just
> trying
> to understand better. Thanks for your response.
>
>