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

[Martin]

Late response / Away from home

Hans-Peter Diettrich wrote:
> Martin Friebe schrieb:
>   
>>>> - 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.
>
>   
Serialization classes are registered on the Model (e.g. By the models 
creator/owner). The are triggered by an actor (controller of a MVC = 
Synedit)

If a none folding component saves the model, it still works.

But it will be easier to switch between different serialization: binary, 
plain text/ini, xml,...

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

But each sub-model has a helper serialization class, which can be 
exchanged to produce a diff output format.

>>>> 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 owner/creator knows.

Lazarus-IDe is such an owner/creator. Lets say Lazarus saves always as 
plain text and a metadata xml-file. Then Lazarus always sets those 
serializers, and knows how to load the data.

If I write my own app, and want binary file-formats, then I use other 
classes for 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.
>   
ACK