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