[Lazarus] The Data-Model for SynEdit / The Data Model for Lazarus [Code Structure / SourceEdit and SyneEdit]

[Hans-Peter Diettrich]

Martin Friebe schrieb:

>>> - The public/shareable model would have to be ref-counted. Or explicit 
>>> ownership would need to be assigned and the owner would need to keep 
>>> track of all Shareholders.
>>>     
>> The latter. The model must know about all views, to be notified of 
>> changes. This suggests a viewer chain, as used e.g. for Windows 
>> clipboard viewers.
>>
>>   
> That are 2 different things.
> Explicit Owner or ref-counting, both was about creation, and destruction 
> of the model.
> 
> You are talking about notification on changes. Each "Synedit" that uses 
> the model becomes an observer of it.

A model is created and destroyed by some owner, e.g. the application. 
When the last observer (view) detaches from the model, the owner can 
decide whether to keep or destroy the model.

> For this it can either enter itself on a list of known observers, or 
> leave a callback reference (a reference to an object-method technically 
> contains the reference to the object). Notifying all observers will then 
> be easy.

I'd vote for a list of observers, but just running into one problem: of 
what type should the observers be?

A common base class is not very appropriate, unless only LazEdit 
observers are allowed. In so far a notification method reference would 
be more appropriate.

> It can be decided, if the Model should detect changes and trigger the 
> notifications (after EndUpdate), or if the current Actor on the Model 
> retrieves the List and sends the Notifications.

ACK, with Actor = MVC Controller.


>>> - The Model can be serialized. Special classes would to this work.
[...]
> Take the idea where you can build your SynEdit with different plugins 
> from the Component palette. You build two SynEdits that should display 
> the same Model. One of the SynEdits is build with folding the other one 
> is not.
> - The one that is not will simply ignore the Folding Data in the model. 
> That will be no problem at all.

It becomes problematic, when the non-folding component would try to save 
the model himself. That's why *serialization* IMO must be done by the 
model, not by arbitrary helper classes.

> - The model will allow to register additional "sub-models" such as 
> folding. therefore the Synedit with the folding will have no issue 
> working with this model. It will simply create the sub-model (if not 
> existent) and register it.

It's okay when a model consists of several helper objects (sub-models, 
data containers), then these classes can implement the serialization of 
their own data - but only the model knows about all its data containers.

>>> The it would only need an appropriate serialize class to save all of them.
>>>     
>> Or an accordingly overwritten virtual method.
>>   
> I prefer an extra class. It will be more flexible

I already noticed your preference ;-)

What about classes of a different implementation (data format...)? Who 
should determine, which of these classes saved some data, and 
consequentially has to be used for loading that data, later? That's why 
IMO every (sub-)model should have built-in code for it's own 
de/serialization.


>>> The Model could also carry callback lists, so the anybody who needs to 
>>> know that it was loaded or saved could register a callback
>>>   Model.AddOnSerailizedCallback( AMethod )
>>>     
>> The beforementioned list of view(er)s. When actions shall be monitored, 
>> then an implementation in the controller seems to make more sense to me.
>>   
> Sorry not exactly sure if I follow? "an implementation in the 
> controller"? An implementation of what?

The controller knows what has been changed, and can send the appropriate 
notifications. Also the controller knows about the views (of different 
kinds), the model doesn't know that. I'd restrict notifications to an 
single type of callback methods (observers in general), perhaps with a 
parameter indicating *what* has gone on.


> To make sure I am speaking of notifications between multiply SynEdits.

The SynEdits (views in general) must not know about each other. The 
controller has to notify all views (observers) of all changes to the model.

> Not between parts within one SynEdit.
> - so the list of Callbacks must be on the model, as it is to be shared.
ACK.

> - the action of triggering the sending of the notifications? (happy to 
> have it in the controller, but not seeing a problem with having them 
> triggered by the model in some cases)
Well, that should do no harm.

> - the implementation of what happens as reaction to the notification? 
> Yes that needs to be in the cotroller

Oops? The *controller* sends the notifications, the *views* react on 
receipt of a notification. A view (or menu...) can send an action 
request (command) to the controller, which executes the action and 
notifies all views about consequential changes to the model.

DoDi