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 _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
