[Cuis] Fwd: Fwd: Patterns

Tue Nov 17 11:36:34 CST 2015

Hi Thierry,

On 11/17/2015 1:51 PM, Thierry Goubier wrote:
> Hi Juan,
>
> 2015-11-17 16:16 GMT+01:00 Juan Vuletich <juan at jvuletich.org 
> <mailto: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
>>     <mailto: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.

Uh, it is not easy to find stuff about that, so I can't really comment.

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

Well, in my opinion View / Model separation is a great property of the 
design of an application. Controller is more of a requirement of the 
ST-80 MVC framework. In principle, I see no problem in merging 
Controller into View. But, in Cuis, it can be argued that the Editor 
hierarchy is essentially a hierarchy of Controllers, and that's ok if 
the decomposition of responsibilities makes sense.

In View / Model separation there are two restrictions that need to be 
honored:
- The Model doesn't know about the possible Views. This means, for 
instance, that it could provide all its services, and exercise all its 
functionality, even if the GUI framework is completely absent. Model 
code should never fail because of this. This is great for moving models 
from and two different runtimes (client, server, gemstone, various 
dialects, etc) and also for writing tests.
- Model behavior should not leak into Views. This means that if the 
views are removed (maybe to be replaced by some others, in the same or 
in another framework), Model should not lose state nor behavior. Model 
must be complete by itself.
So, the idea is essentially to protect the integrity and consistency of 
Models.

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

Well, lets assume a Model with 2 collections of elements. To make it 
sound a bit more concrete, lets call them Orders and Assets. And lets 
assume that the UI has some place(s) from where the user can drag many 
kinds of objects, like Orders, Assets, between others. Now, the user 
drags an Asset and wants to drop it into the Orders list. Given that the 
widget for the Orders list supports dropping, lets assume that its 
'dropActionSelector' is #addOrder:. This #addOrder: model method would 
be called with an Asset. So, #addOrder: could answer false, to let 
sender know that the addition was rejected (because it was not an 
Order!). It makes sense to have the method in ListWidget that calls 
'dropSelector' check for the result, and if it is false, let the user 
know that the drop was rejected, for instance, by keeping the dragged 
object in the hand.

>
>
>>     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).

"View model" is a bit a misleading name. I'd say all this belongs in the 
Views world.

Besides, the method called to update Views after Model changes should 
not modify the Model. In this way, there would be no extra Model events 
triggered, and spurious updates would not occur. This might require 
enhancing the Views framework, if not mature enough.

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

Hopefully, it will be less :)

Cheers,
Juan Vuletich

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