I still don't think I quite get MVP

Oh how I wish I understood MVP inside out but even when I read the Twisting
the Triad paper again and again, and think that I'm just about there, there
are still little niggles that make me think I'm missing something.

I completely appreciate Dolphins idea to abandon the controller class as it
does seem a bit dated and not suited to Windows programming. But without the
controller and doing event handling on the application model which is how I
work in VSE (lazy MVC?) and I'm sure other widget based systems are the
same; again there are normally view resource(s) on the application model, it
just feels a very similar system only with the letters changed until you get
into the lower level details, i.e. a check box, toggle button are examples
of BooleanPresenter which I do like for its elegance but not yet convinced
it adds much more than that.

As far as I can tell the M in MVP refers to domain models which are a part
of MVC only not in the name. Their M is the Dolphin P i.e. the application
model / presenter and the V's are the same. This seems like an identical
arrangement bar the one mention about having an indirect link between the
application model and view. It is apparently this indirect link that means
programmers get lazy, don't create view classes and instead access widgets
straight from the application model. This then ties the application model to
the view and it says this is bad because it violates having multiple views
onto the same application model. But Dolphins implementation feels the same
since there is a one to one map between the presenter and view. The domain
model objects remain the same like in MVC but you still have to create a new
presenter instance on them to provide a different view (like the
MethodBrowser which is how I expect it to be used) but not by putting a
different view onto the same presenter instance. With a 1-1 relationship
like this in both systems, I don't see the harm in doing actions like
componentAt: as long as your views name the widgets the same, but this is
similar to MVP since you tie a presenter to a named widget which must be the
same in all views. In fact if you do create your view classes in MVC you can
have multiple views onto the same application model instance; I'm not saying
thats necessary a useful thing but it appears like MVP is less flexible in
that respect and only serves to provide a slightly cleaner approach to 1-1
view to presenter modelling. Am I missing something here?

The power I see comes in a widgets ability to coerce itself into a domain
model aspect i.e. with a NumberPresenter you can have a textbox, slider,
spin control etc and you need no knowledge of Windows eventing as they'll
all end up in the presenters valueChanged. This is great but could be
construed a little confusing to beginners as views have publishedEvents but
its generally presenters that are used in the schematic wiring. I also would
have thought an MVC system can do the same as you hook the widget up to a
model aspect and it sorts everything out - I think VAST and VisualWorks both
work like this. Anyway what this all boils down to is not liking having to
write the methods which sit in the middle as they feel largely automatic -
createComponents, defaultModel, model: etc - we all knew it was going there
right and I don't think I'm completely alone thankfully :)

I know that there have been mentions of a schematic generator but I think
you're already there with whats available. When you drag a widget onto a
view, you have fixed its presenter. You can't have the same widget with
different presenter types for each view since you fix it in your
createComponents. So I am completely behind CJD's Presenter Generator but
wondered if this is a bad thing as I wouldn't expect mention of a schematic
generator level of abstraction or lack of more auto generated view support
in the base product. The problem we have though is that some of the
information is missing. Basically this goodie tool works by backtracking
from a widgets type to ascertain what presenter it came from - but this true
information has been lost by the time it hits the form. Therefore I
completely appreciate what Chris has done but it can never be perfect as a
TextEdit view could be a number of different types of presenter and requires
manual updating. If this presenter information could be maintained, the
createComponents could be completely automatic; is there any way to do this?
I think that we should always simply obtain the "or" result of every widget
on every view for that the presenter. I'd even go as far personally to also
write the model: code - we have the name of the widgets and I know I and
many others would often have the domain model selector be the same as the
widget name; I do when I'm manually coding and have been known to make
errors! Then I'd even have it create the domain model class, variables,
getters/setters and defaultModel method all from the view composer. I
appreciate that this is very fully into goodie territory but I think it
would add a lot of value to everyone, most notably those who arrive from
quick dirty app / widget based environments like VB and C# and complain
about all of the extra effort required in setting up MVP; yet still adhering
them to proper domain application seperation. I probably haven't done enough
big application development to appreciate that the overhead of this manual
coding is probably tiny in the bigger picture but noone likes writing too
much code!

Just as an aside from what I could tell of VisualWorks, it allows you to set
an application model selector to a widget and is faster to begin with but
you still have to manually write more complex code to switch to your domain
model when you're ready to beef it into a real app. So I guess Dolphin is
even better than that but it could be perfect for gui development just as it
is for bringing the best programming language to the mainstream in the best
IDE available :)

Regards,
Chris

Hello Chris,

Have you by any chance checked the forum archives going back about 6
weeks?  I'm not suggesting that you wouldn't think to do that, but I
just came through the same subject as you are now, both as a neophyte to
Smalltalk and to Dolphin.

Andy Bower, Chris Uppal, and Ian Bartholomew (among others) provided
positively brilliant, in-depth answers to my very open-ended questions
(and some not-so-open-ended questions) about MVP.  I can tell you that,
after having read their replies, I indeed understood MVP.  No doubt many
nuances still remain to be identified and mastered, but I feel I now
have a working knowledge of the broad framework, specifically because of
these posts.

If after reading these posts you are still having issues, then if you
like I can discourse a bit, from one MVP starter to another and under
the watchful eye of the few stewards I mentioned above, about my
experiences in designing an extension to the TreeModel.  It's an
extension that embraces a number of elementary issues revolving around
full MVP, events, and extending the Dolphin framework non-invasively.
In the next few days, I will be posting to Ian's website the third
iteration of this extension.

Cheers,

Eric
as
> it
> does seem a bit dated and not suited to Windows programming. But
without
> the
> controller and doing event handling on the application model which is
how
> I
> work in VSE (lazy MVC?) and I'm sure other widget based systems are
the
> same; again there are normally view resource(s) on the application
model,
> it
> just feels a very similar system only with the letters changed until
you
> get
> into the lower level details, i.e. a check box, toggle button are
examples
> of BooleanPresenter which I do like for its elegance but not yet
convinced
> it adds much more than that.
>
> As far as I can tell the M in MVP refers to domain models which are a
part
> of MVC only not in the name. Their M is the Dolphin P i.e. the
application
> model / presenter and the V's are the same. This seems like an
identical
> arrangement bar the one mention about having an indirect link between
the
> application model and view. It is apparently this indirect link that
means
> programmers get lazy, don't create view classes and instead access
widgets
> straight from the application model. This then ties the application
model
> to
> the view and it says this is bad because it violates having multiple
views
> onto the same application model. But Dolphins implementation feels the
> same
> since there is a one to one map between the presenter and view. The
domain
> model objects remain the same like in MVC but you still have to create
a
> new
> presenter instance on them to provide a different view (like the
> MethodBrowser which is how I expect it to be used) but not by putting
a
> different view onto the same presenter instance. With a 1-1
relationship
> like this in both systems, I don't see the harm in doing actions like
> componentAt: as long as your views name the widgets the same, but this
is
> similar to MVP since you tie a presenter to a named widget which must
be
> the
> same in all views. In fact if you do create your view classes in MVC
you
> can
> have multiple views onto the same application model instance; I'm not
> saying
> thats necessary a useful thing but it appears like MVP is less
flexible in
> that respect and only serves to provide a slightly cleaner approach to
1-1
> view to presenter modelling. Am I missing something here?
>
> The power I see comes in a widgets ability to coerce itself into a
domain
> model aspect i.e. with a NumberPresenter you can have a textbox,
slider,
> spin control etc and you need no knowledge of Windows eventing as
they'll
> all end up in the presenters valueChanged. This is great but could be
> construed a little confusing to beginners as views have
publishedEvents
> but
> its generally presenters that are used in the schematic wiring. I also
> would
> have thought an MVC system can do the same as you hook the widget up
to a
> model aspect and it sorts everything out - I think VAST and
VisualWorks
> both
> work like this. Anyway what this all boils down to is not liking
having to
> write the methods which sit in the middle as they feel largely
automatic -
> createComponents, defaultModel, model: etc - we all knew it was going
> there
> right and I don't think I'm completely alone thankfully :)
>
> I know that there have been mentions of a schematic generator but I
think
> you're already there with whats available. When you drag a widget onto
a
> view, you have fixed its presenter. You can't have the same widget
with
> different presenter types for each view since you fix it in your
> createComponents. So I am completely behind CJD's Presenter Generator
but
> wondered if this is a bad thing as I wouldn't expect mention of a
> schematic
> generator level of abstraction or lack of more auto generated view
support
> in the base product. The problem we have though is that some of the
> information is missing. Basically this goodie tool works by
backtracking
> from a widgets type to ascertain what presenter it came from - but
this
> true
> information has been lost by the time it hits the form. Therefore I
> completely appreciate what Chris has done but it can never be perfect
as a
> TextEdit view could be a number of different types of presenter and
> requires
> manual updating. If this presenter information could be maintained,
the
> createComponents could be completely automatic; is there any way to do
> this?
> I think that we should always simply obtain the "or" result of every
> widget
> on every view for that the presenter. I'd even go as far personally to
> also
> write the model: code - we have the name of the widgets and I know I
and
> many others would often have the domain model selector be the same as
the
> widget name; I do when I'm manually coding and have been known to make
> errors! Then I'd even have it create the domain model class,
variables,
> getters/setters and defaultModel method all from the view composer. I
> appreciate that this is very fully into goodie territory but I think
it
> would add a lot of value to everyone, most notably those who arrive
from
> quick dirty app / widget based environments like VB and C# and
complain
> about all of the extra effort required in setting up MVP; yet still
> adhering
> them to proper domain application seperation. I probably haven't done
> enough
> big application development to appreciate that the overhead of this
manual
> coding is probably tiny in the bigger picture but noone likes writing
too
> much code!
>
> Just as an aside from what I could tell of VisualWorks, it allows you
to
> set
> an application model selector to a widget and is faster to begin with
but
> you still have to manually write more complex code to switch to your
> domain
> model when you're ready to beef it into a real app. So I guess Dolphin
is
> even better than that but it could be perfect for gui development just
as
> it
> is for bringing the best programming language to the mainstream in the
> best
> IDE available :)
>
> Regards,
> Chris
>

"Eric Taylor" <[hidden email]> wrote in message
news:000b01c6a143$2dac86c0$6500a8c0@server...
I have read numerous posts on MVP including that one but went back to brush
up. As always the Smalltalk way of looking at the current uses in the system
seems a better way and makes a lot more sense, but it can be more difficult
than a good tutorial and many won't have that patience! It seems to me that,
as it suggests, a presenter serves as a way of communicating with like
widgets regardless of their appearance; and it has to do this with
composition and a pattern without the aid (and hinderance) of multiple
inheritance. This is interesting to me as I want to look at a mixins
solution using composition rather than inheritance as an alternative to
traits.

So the boolean views can be scattered amongst the view hierarchy, underneath
abstract command buttons, abstract check buttons and yet need to group
boolean functionality underneath the presenter. So I went back to the paper
as I always kind of knew this but didn't see how it fit, but crucially I
interpreted the key bit that didn't make sense differently - I read it that
doing a componentAt: is bad because it stops you opening multiple views on
the same application model. My argument was that presenter/view is no
different since you must create the pair. But I think I now realise that
what they are saying is that you are manipulating a widget directly which
could have a different representation elsewhere and won't work. The
presenter makes sure that anything you do to it will be understood by all
views that display it and is safer. Again that does create overhead, a large
number of methods in some presenters just route the message straight through
as its common to all views (maybe mixins would help here?) but I can
appreciate that something like a ListPresenter itemCount needs a different
approach per widget because of the cruddy Windows API! So I probably won't
completely get it until I've written some complex applications but its not
especially beginner friendly in its current incarnation and I think this
could be argued for several generations of Dolphin and will scare many away;
combined with the already big learning curve that Smalltalk brings with
unfamiliar syntax and image based working being so wacky to a new user. I
think the overhead related in creating a simple GUI isn't helping because I
have first hand experience of it creating frustration with someone I'm
trying to prise away from the dark side :)

I think the main query still stands to assist in generating these apps
quicker and appealing to widget driven programmers; I can appreciate that it
won't be much benefit in areas such as your browsers but consider for
something like the FileSystemMonitor how much more a beginner would take to
it. If we create a presenter createComponents which is a composition of
every widget on every view you have, is that in keeping with the
framework... I personally can't yet see the benefit of a schematic generator
as you fix the presenter type as soon as a widget goes on a view and it
feels like you have already done the work. I think an automated domain model
hook up could be used in many circumstances and worked back from for more
complex functionality, but need to understand if this theory is flawed and
if we can get at a presenter type for a widget cleanly

Regards,
Chris

ChrisB wrote:

> The presenter makes sure that
> anything you do to it will be understood by all views that display it and
> is safer. Again that does create overhead, a large number of methods in
> some presenters just route the message straight through as its common to
> all views (maybe mixins would help here?) but I can appreciate that
> something like a ListPresenter itemCount needs a different approach per
> widget because of the cruddy Windows API!

I'd say that it is the View's responsibility to ensure that it acts
polymorphically with other Views used by the same Presenter class(es).

Which, incidentally, is one reason that introducing a new kind of View involves
significant forward-looking design work if you don't want to constrain the
implementation or design of other Views which may be created to work with the
same Presenter.

    -- chris