[Cuis] Fwd: Patterns

[Thierry Goubier]

2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:

> Hi Thierry,
>
>
> On 11/17/2015 1:42 AM, Thierry Goubier wrote:
>
>> Le 17/11/2015 02:47, Germán Arduino a écrit :
>>
>>>
>>>
>>> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
>>> <mailto:juan at jvuletich.org>>:
>>>
>>>     __
>>>
>>>     Well, I don't like the #open method in the model. The idea of View /
>>>     Model separation is that views know about models, but models don't
>>>     know about views. A Model should exist independently of being used
>>>     from Morphic, MVC, Seaside, or any other UI framework. It could
>>>     live, for example, in a Gemstone database with no UI at all. Or ir
>>>     could travel to and from other systems, like VA Smalltalk, where the
>>>     UI framework is completely different from Cuis'.
>>>
>>>
>>> Interesting, really I never heard of the use of  #open at the model or I
>>> do not remember it at all, but I think similar to Juan.
>>>
>>
>> Hum, #open has to go somewhere, so...
>>
>> Either it goes into a sort of Application Model, which regroup the duties
>> associated with the application (the view + model + whatever is necessary
>> in environment X), or it goes into an Application View which then has model
>> concerns in it (it knows how to start or connect to the model, it knows
>> what the model is composed of to connect subviews to model elements,
>> etc...).
>>
>>
> The idea of view / model separation is pretty well explained in "Inside
> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>

Sadly, that view / model separation encounters pragmatic issues  when
dealing with things more complex than standard widgets, such as your
typical domain drawing editor. This is the fundamental reason for me to
consider that Morphic departed from that model, and that the pinacle of
that M / V separation is the M2VC of VisualWorks.

Newer models in the literature around those years such as PAC proposed
better abstractions, but they were never implemented.

Now, it's interesting to see you advocate that model on top of Morphic.


> I agree that an Application object or such might make sense when you are
> building an application, especially if you need to deal with en external
> environment. But here we were talking about whether the Model classes
> should know about Morphs or not.


In theory, no.

In practice, if you want a well tuned gui, I consider that yes, they need
to be aware of them.

So the most elegant way I've used is the two models: a pure, abstract
model, totally view independent. And a pragmatic, closer to the view /
aware of the view, application model as an mediator.


>
>
>     I think it is better for the View to start it all.
>>>
>>>
>>> +1
>>>
>>
>> I prefer to model an Application concept in the target desktop
>> environment if I want to model highly portable stuff.
>>
>> That application concern can be folded into a dedicated view if that is
>> the preferred convention in the target environment.
>>
>> Regards,
>>
>> Thierry
>>
>
> I wonder how would this result in practice. Do you have some examples to
> share?
>

I have a complex example, a system browser, would that fit?

Regards,

Thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/57a1be52/attachment-0004.html>