[UI] ToolBuilder

[tim Rowledge]

On 10-Sep-07, at 12:57 AM, Bert Freudenberg wrote:

>
> On Sep 10, 2007, at 7:56 , Jason Johnson 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.
>
> I'm not familiar with Dolphin but this reminds me of the value/ 
> value: mess in VisualWorks where all you ever saw is value sends.  
> This is indeed rather flexible but I have the impression that  
> Squeak's "pluggables" enhance readability and debuggability.

I'd say that the MVP stuff is using the adaptor pattern; have the  
views use value/value: and make the P (?) handle converting that to  
anything your main model uses. I must admit that in general I find it  
easier to follow the pluggablview approach where the adaptor code is  
simply included in the view's protocol. It all works out the same in  
the end.

People need to remember that there is nothing special about the model  
of a view/pane/whatever. It's just an object that the view talks to.  
It doesn't have to be the BigDomainModel. You can have little models  
that talk to BigModels. You can have littlemodels talking to adaptors  
to let them talk to a Mediummodel which works with a bunch of others  
to talk to a BigModel which ... etc etc.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: HALT: No-Op