[UI] ToolBuilder

[Igor Stasenko]

On 10/09/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> 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.
>

This is a good way to go. Aspects in Dolphin is pretty much same what
i called Accessors.
A morph, instead of having rigid selector to get interesting value
from model could have an accessor instead.
There can be different kinds of accessors each of them can define own
way how to get value. A trivial one is by sending unary message to
model with given selector.

model perform: #someselector.

But you can construct something more complicated:

(model at: #key1) at: key2

or

model collect: [..] thenSelect: [..]

While ways how to get value can be very different, at morph side it
always looks like following :

for getting:

value := myAccessor getValueFrom: self model.

for setting:

myAccessor setValueIn: self model value: someNewValue.

In such way we can connect any number of views for same model, which
can access its data in very various ways. And  view is not depends
from any aspects of model like existence of methods with given
selector or not.

Eventually such level of abstraction can be simply used for
constructing UI with IDE tools for any kinds of models/views. You
simply can pick any morph and then define a ways how it will access
properties of model by providing required accessors.
This approach is much more flexible than always dealing with unary 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.).
> _______________________________________________
> UI mailing list
> UI at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>


-- 
Best regards,
Igor Stasenko AKA sig.