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

[Martin Friebe]

Hans-Peter Diettrich wrote:
> 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.

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

>> - The Model can be serialized. Special classes would to this work. 
>> Therefore a model can be saved to one file, or to a set of files
>>     
>
> A separation in multiple classes is dangerous, because changes to the 
> model (number or type of values) had to be reflected in all related 
> classes, in every project using that model.
>   
IMHO an addition to the model does not need to be reflected in all 
Classes dealing with it.
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.
- 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.

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

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

To make sure I am speaking of notifications between multiply SynEdits. 
Not between parts within one SynEdit.
- so the list of Callbacks must be on the model, as it is to be shared.
- 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)
- the implementation of what happens as reaction to the notification? 
Yes that needs to be in the cotroller


Best Regards
Martin