Alternate GUI to MVP

Why can't there be an alternative GUI (similar to Java's) to allow one
to use non-MVC/MVP style development?

Everyone talks how desirable MVC is. Agreed it is desirable but should
not be the only choice. Especially when there is a need to attract
newcomers from other languages like Java and VB and to write some
quick and dirty apps.

I have been looking at how Java implements Swing. It does not follow
the Model-View concept and it's up to the programmer to design with
MVC in mind if one wishes. Most programmers on small to medium
projects would probably not use pure MVC if they had a choice. Is that
so bad?

Dolphin forces you to design with MVP. My proposal is to design a
Swing like GUI that follows the Java implementation.

The View composer should have an option to generate pure code with
empty methods and events subclassed from a set of basic component
classes. (Maybe the code could come from a user customizable template)

All I ever want to do, is to have the set of basic events and methods
of each component appear so I can write my code from there.

I would like to see, my onClick, onChange, onWhatever as well support
methods to refresh and update and control a component.

I know this may sound a little like ranting, but I am just frustrated
that I am forced to use something complex for quick and dirty jobs.
For a smooth language like Smalltalk and so simple to use,  the MVC
concept (although idealistic) is so complicated.

I don't want to have Models, Views and Presenters. I want all my code
to be inside events and methods for each of the controls.

I know this is not a trivial thing for you to implement, but I am
still not convinced that MVP is easier or necessary to use for GUI
apps.

Regards,

costas

Costas,

> Dolphin forces you to design with MVP.

I'm not sure that's really true.  There is even provision to create one's
own view system, and the remainder of the framework could be replaced as
well.


> The View composer should have an option to generate pure code with
> empty methods and events subclassed from a set of basic component
> classes. (Maybe the code could come from a user customizable template)

No argument there.


> All I ever want to do, is to have the set of basic events and methods
> of each component appear so I can write my code from there.
>
> I would like to see, my onClick, onChange, onWhatever as well support
> methods to refresh and update and control a component.

The refrest/update at least was a relative weak spot of Dolphin's MVP
framework.  Early on, I found it very difficult to "push data into a
presenter"; however, #refreshContents will usually fix a stubborn view.
Also, Dolphin has improved a lot over time, and some things that were
difficult a couple of years ago are fairly smooth now.


> I know this may sound a little like ranting, but I am just frustrated
> that I am forced to use something complex for quick and dirty jobs.
> For a smooth language like Smalltalk and so simple to use,  the MVC
> concept (although idealistic) is so complicated.

I agee that MVC can be complicated, especially when one tries to fit the
controller concept into a modern GUI which expects to do a lot of the
controller's work.  However, MVP provides a very nice alternative, and
Dolphin's lean implementation of MVP is nice to use.


> I don't want to have Models, Views and Presenters. I want all my code
> to be inside events and methods for each of the controls.

You are basically describing VB with Smalltalk syntax.  Within those
constraints, views can be largely transparent to you.  If you think of
presenters as the "controls" that you drag onto a "form" (composite
presenter), then about all you'd need to make it work as you want is
something that adds trigger wiring and writes a method into your composite
presenter.  Presumably you'd let each sub-presenter use its default model,
and send a lot of #value[:] messages to the subpresenters.

Have a good one,

Bill

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

Costas Menico <[hidden email]> wrote in message
news:[hidden email]...
...
> The View composer should have an option to generate pure code with
> empty methods and events subclassed from a set of basic component
> classes. (Maybe the code could come from a user customizable template)
>
> All I ever want to do, is to have the set of basic events and methods
> of each component appear so I can write my code from there.
>
...
> I know this may sound a little like ranting, but I am just frustrated
> that I am forced to use something complex for quick and dirty jobs.
> For a smooth language like Smalltalk and so simple to use,  the MVC
> concept (although idealistic) is so complicated.
>
...

I was frustrated with MVP as well.  It seemed like there was a lot of
overhead just to make a simple UI.  This was what inspired me to develop my
Presenter Generator goodie.  It is not a total solution yet, but I have
found it makes MVP much easier for me to implement by generating some
skeleton code.  You can look at what I have here:
http://www.mitchellscientific.com/smalltalk/ .  Some of what you are
suggesting could be retrofit into the existing MVP implementation.  I think
that if there were some default mapping between views and presenters MVP
could be automated a bit more.  For example I find myself using a
ListPresenter with a ListView most of the time.  While there can be power in
being able to use different presenters and views, most of the time I find
myself using standard view presenter pairs.  My tool allows me to set
default presenters for certain view classes.  I think an improvement in
Dolphin might be to have a better way of working with views and presenters
together combined with more code automation.  I don't know if I would assume
that any of my generation code was good enough for OA, but I certainly would
let them use it if they wanted to.

Chris

On Mon, 17 Sep 2001 18:48:50 -0400, "Christopher J. Demers"
<[hidden email]> wrote:

Yes, that was my other issue. Why do I need to have a seperate
presenter and view? I understand the flexibility of it but like you
said many of the views and presenters go together as a pair most of
the time.

I guess that would go a long way into making the implementation of
GUIs less of a shock.  There should be a way to combine presenter/view
and provide an empty default model class with all the wiring in place.

Chris, Costas,

> I was frustrated with MVP as well.  It seemed like there was a lot of
> overhead just to make a simple UI.  This was what inspired me to develop
my
> Presenter Generator goodie.  It is not a total solution yet, but I have
> found it makes MVP much easier for me to implement by generating some
> skeleton code.  You can look at what I have here:
> http://www.mitchellscientific.com/smalltalk/ .

I agree that there is room for tools that help out by writing skeleton
methods.  One of my current projects made it almost essential to create
something along those lines because the GUI is derived from external
specifications that can be parsed, and it's a moving target.  I have code
that decides which sub-presenters to create, generates the view resources
using a replacement ViewComposer, and writes the code to make the presenters
work.  It's not completely automated: the code decides what to create and
does the tedious work; a fair number of class methods generate interval-like
objects that specify how to break things up across multiple panes, but, they
bother only with the first and last field on each pane and complain if the
expected names don't appear.


> Some of what you are
> suggesting could be retrofit into the existing MVP implementation.  I
think
> that if there were some default mapping between views and presenters MVP
> could be automated a bit more.  For example I find myself using a
> ListPresenter with a ListView most of the time.

What's wrong with #defaultView?  I think the mapping that's missing is
instead between published aspects of a model and presenter classes to
represent them..  Of course, one would need to be able to override the
choice of view resource for any individual aspect, but, that could be done
by exception.

Have a good one,

Bill

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

Bill Schwab <[hidden email]> wrote in message
news:9o6u8f$i5r$[hidden email]...
...
>
> What's wrong with #defaultView?  I think the mapping that's missing is
> instead between published aspects of a model and presenter classes to
> represent them..  Of course, one would need to be able to override the
> choice of view resource for any individual aspect, but, that could be done
> by exception.

The defaultView method is a good map from a Presenter to a View, however I
think I wish there was a defaultPresenter aspect on Views.  I tend to build
my views before I decide upon presenters.  I would not mind making a
Presenter decision while I am making my view choices, but the way things
tend to flow for me is that I design the view, then I pop in the presenters
required to present my models to the views I have chosen.  Once I have
inserted a View object I don't think there is any easy way to track it back
to its "default" presenter.  The way things are now it seems that we make a
decision for each subview.  Then we have to go back and make a decision
about a subpresenter for each subview.  I feel like some kind of single pass
approach where the view and presenter decisions could be made in one context
might be nice.

You are correct about the value of published aspect to presenter mapping.  I
had been thinking about something like this, I did not think of using
published aspects but rather a template instance.  I envision something like
MS Access' Form Designer where you can drag DB fields on to the form to
create data bound text boxes with labels, it could do the views and
presenters at once.  That would be cool.

I have not generally been publishing my model aspects.  Do you do this?  I
never seemed to need this, except that I have to do something similar for
ReStore class definitions.  I guess there is value from a documentation
perspective.

Chris

Chris,

> The defaultView method is a good map from a Presenter to a View, however I
> think I wish there was a defaultPresenter aspect on Views.  I tend to
build
> my views before I decide upon presenters.  I would not mind making a
> Presenter decision while I am making my view choices, but the way things
> tend to flow for me is that I design the view, then I pop in the
presenters
> required to present my models to the views I have chosen.  Once I have
> inserted a View object I don't think there is any easy way to track it
back
> to its "default" presenter.  The way things are now it seems that we make
a
> decision for each subview.  Then we have to go back and make a decision
> about a subpresenter for each subview.  I feel like some kind of single
pass
> approach where the view and presenter decisions could be made in one
context
> might be nice.

Good point.  The answer might be to have the VC could keep track of the view
resources that you've pasted (therefore keeping both presenter and view).
My code/view generator builds such a map as it assembles views and then uses
it to write code for the presenters.


> You are correct about the value of published aspect to presenter mapping.
I
> had been thinking about something like this, I did not think of using
> published aspects but rather a template instance.  I envision something
like
> MS Access' Form Designer where you can drag DB fields on to the form to
> create data bound text boxes with labels, it could do the views and
> presenters at once.  That would be cool.
>
> I have not generally been publishing my model aspects.  Do you do this?

Not typically.  I tried making some runtime use of the idea, but, that
started conflicting with improved stripping by Lagoon so I've gotten away
from it.

Have a good one,

Bill

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