[UI] ToolBuilder

[Karl]

Igor Stasenko wrote:
> 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.
>   
Have you looked at the old Fabrik demo project. I lives in images up to 
around Squeak version 2.8. The demo shows how you can build a browser by 
querying the system for different views. It shows a possible way to 
build interfaces on the fly, to your specific need.

Karl
>   
>>>> 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
>>
>>     
>
>
>