[Cuis] Fwd: Fwd: Patterns

[Thierry Goubier]

Hi Juan,

Le 17/11/2015 18:36, Juan Vuletich a écrit :
> Hi Thierry,
>
>>
>>
>> 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.

InterViews was kept alive as the ivtools for long, very long after 
InterViews lost to Motif as the X Window toolkit. Fresco, InterViews 
successor, was also very interesting.

HotDraw is old as well. But I did some cool stuff with it (a hypermedia 
system, in 1993).

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

I do agree with that objective, but, in practice, what I find as a 
result is that an additional layer (model mediation or the M2 of MMVC) 
helps immensely by:

- regrouping certain model features which are introduced to satisfy view 
requirements...

   - For example a pure model can just have a copy or save to file 
operation, but a view would like to have a feedback on the length of the 
operation. In non gui mode, having the model expose that sort of 
information is a needless waste of code and resources. This would better 
be carried by a layer on top (which is still a model IMHO, since it 
maintain a certain level of decoupling with a view).

- Expose explicitely certain adaptations which are made for a specific 
toolkit (they are in that model).

- Allow for user-features oriented models to appear on top of the pure, 
abstract model

   - In a browser, one can imagine scoped models of the code as a 
user-oriented feature that a disconnected mode doesn't need to integrate.

Nothing really grandiose or earth-shattering, mind you. Just convenient.

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

Hum, I was more thinking of what I am dealing with at the moment, which 
is a drop in the Orders list is a drop on a specific order item, which 
has to tell:

- during the drag, if a drop would be honored
- after the drop, if it is accepted or rejected
- and, if accepted, that specific order item changes state and is shown 
as such (and may also change the number of order items, etc...)

I found, when doing that, to have an intermediate model on top of my 
Asset/Order object to mediate with the drag and drop API very usefull 
(that is, what is displayed and dragged are Views on AssetModels which 
are themselves observers of Assets).


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

As I said, it may be moved into the View world, in the sense that it 
holds view-related concerns. But, at the same time, it has Model like 
decoupling from the Views.

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

I'll let you have a try at that :)

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

I'm certainly looking forward to it.

Regards,

Thierry