[UI] ToolBuilder
Jason Johnson
jason.johnson.081 at gmail.com
Mon Sep 10 05:56:56 UTC 2007
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.).
More information about the UI
mailing list