[Cuis] Fwd: Fwd: Patterns

[Thierry Goubier]

Hi Juan,

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

> Hi Thierry,
>
> On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>
>
> 2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:
>
>> ...
>>
>> 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 first time I hear this. Can you elaborate or provide
> references? I worked on several mid-size to large projects that did strict
> view / model separation, and I never saw "pragmatic issues" (that couldn't
> be solved by a good design).
>

I would give HotDraw, and some of the original design pattern work on
editors, especially the parts derived from the InterViews toolkit.

Now, I used to be pretty up to date on the literature and some of the
criticism of the MVC model (especially the division between V and C) but my
memory of that time is all fuzzy.

> 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.
>
>
> PluggableMorphs attempted to follow this model (and give model
> compatibility between Morphic and MVC). Etoys (if I remember correctly) do
> the same, only that calling the model a "Player" and the view a "Costume".
> Later, people forgot about view / model separation, and Squeak became
> legacy software, in part because of that.
>

Maybe. I'm not sure of that particular factor. I have the feeling that
there is no clear and honest analysis on the state of GUI toolkits in that
universe, for present and future ones.


> 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.
>
>
> Please elaborate, or provide references.
>

What would you think of a drag and drop feedback which is dependent of the
type of the model elements?


>
>
> 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?
>
>
> Sure.
>

Well, a short estimate on that particular application is that, linked with
the pluggable morphs, 10 to 20% of the code in the application model is:
- widget creation, setup, layout
- dynamic morph addition / removal when activating certain functions on the
model
- workarounds the pluggable morphs api to:
  - dynamically refresh parts of the inside of widgets
  - disconnect then reconnect links between widgets so that the
model-triggered update of one does not change the state of the other one
(i.e. protect the model from unwanted view triggered updates when the model
is changing part of its contents).

This application model uses mainly two widgets.

I do have a long term plan to port that to Cuis, and I expect I will have
to write that very same code somewhere (maybe more, maybe less).

Regards,

Thierry


>
> Regards,
>
> Thierry
>
>
> Cheers,
> Juan Vuletich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/fbfd618b/attachment-0004.html>