[UI] ToolBuilder

[Jason Johnson]

On 9/10/07, tim Rowledge <tim at rowledge.org> wrote:
>
> > Right. Without pluggability, you're limited to one view per model.
>
> Well strictly speaking one view of any particular type in practice,
> since most implementors end up using selectors like #getList and
> #getText etc :-)

Just to make it more clear what I'm talking about here, in Dolphin's
MVP you had a presenter for any data type, and Aspects are what is
used to actually talk to the models.  So you would never have
#getList/#getText type stuff.  The View is always just calling
#value/#value: on what ever it's viewing.  It is up to the Aspect to
actually translate these to the correct selector.

> > So I went back to the one-view-per-model pattern, with the main
> > model holding a collection of sub-models and communicating through
> > them.
> That can work too; in fact it's pretty much what Tweak formalised (a
> proper class of graphical model as well as the application/domain
> model etc) and really it is what the Browser class is/was fumbling
> toward. I even wrote a paper on it in the dark ages around '88 or so.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> "How many Motie Mediators does it take to chage a lightbulb?" "Are
> you insane? Only Crazy Eddie would want to change *anything*!"

Now I'm curious.  Are some people really not convinced that tying the
"Forms" style UI (model directly to the viewer) is a bad idea?  I was
under the impression this was sort of settled after all the problems
with the "Forms" style viewers used by VB, Borlands C++ builder and so
on (i.e. very fragile, little reuse, etc.).