>>> * ModeController also have saveMap/loadMap methods. Do you expect these >>> methods to have different implementations in different mode controllers? >>> Otherwise wouldn't it be better to make them static methods of some >>> separate, globally accessible class? >> Yes, for instance freemind now has a so-called file mode where file >> system is shown and can be navigated as a mind map, but there is no >> legal "save" operation. > Since not all ModeControllers would implement it, wouldn't it be better to > move them elsewhere? I was thinking maybe we could make them static > members of a separate class named MapXML or something providing these two > functions as static utility functions - the idea being that these are the > only two functions that defines our XML format for ".mm" files. That way: > * The ModeControllers who do support save/load can simply define > wrappers to indicate these maps are saveable (maybe they will implement an > interface named SaveableMaps) > * The ModeControllers who do NOT support them can still use them as an > "Export as FreeMind Maps" option to save a copy of the current state of > mindmap as it exists into a normal-mode mindmap.
I see that implementation of the methods could delegate them to some other objects. I do not understand why such methods should be static. >>> * There are 4 different Observer classes shown on the same page. It does >>> not seem to mention which class has the "add*Observer" methods. In case >>> ModeController was intended, doesn't it seem unusual that someone trying >>> to listen for such events would be required to register the listener to >>> every single active ModeController implementation? Once again, it does >>> seem like firing/managing such listeners could be done from a separate, >>> globally accessible object. >> I have in mind that the extensions added to the mode controller (as it >> is an ExtensionCollection) could automatically become the listener if >> they implement the required interfaces. The reason for it is that the >> extensions of the mode controller are property controller responsible >> for creating/loading/saving/deleting of the property objects. > I see. One thing though, doesn't that mean identical copies of observer > registry (list of observers) are being separately maintained in the > different ModeControllers. I know this is not a huge performance issue, > but the reason I'm pointing this out is this: I was planning a new design > where some core classes would hook in as observers as well. That will > probably force me back to manually register listeners to every > ModeController, or keep an "extension component" for these core classes as > well which will have its hook points automatically by this method. Neither > of them sounds good. I have provided an extra observer collection for models but not for controllers, and you could introduce an observer collection for controllers too. Dimitry ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freemind-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freemind-developer
