|
Hi Chris and Ray, thanks for your points. I second that first the design goals should be defined. So let me write some things about them. == goals of the proposed refactoring == Ray wrote: > The biggest problem I've run into, when trying to create the new Chris wrote: > I second this. We need to decouple the main classes for sure. Identifying of loosely coupled components is the main design task for me too. And I have an idea. Every mind map node can have many different properties like text, font, colors, edges, clouds, attributes and so on. Such properties are often mutually independent: there is no dependencies between attribute data and cloud data. Consequently models of such properties and user actions grouped around them can belong to different loosely coupled packages. The property models can be attached to the MindMaps and MindMapNodes as Extensions. The property controllers can be attaches to the ModeControllers as their extensions. Some of those properties like node attributes or node text can become its own view component (AttributeTable and MainView) which can be added to NodeView using its add(Component) method coming from JComponent superclass. It makes a perfect separation possible. The others properties like clouds should be interpreted by the NodeView directly. Chris wrote: > An empty interface for extensions means that the main program can'tAgreed! For receiving of the signals I have proposed observer interfaces which are called from the ModeController for each Extension implementing them.  But the "kernel" packages should no nothing specific about the node or map properties. (Some exceptions from this general rule for NodeView and MapView are needed). For informing of the extension package (like e.g. icon) about the changes in some model the package can either manage a list of observers directly in his own model or add his observers to the correspondent node model observers (MindMapNode.getObservers()) and use the visitor pattern for iterating them and calling their property specific methods. Methods allowing for registering UI items like MenuItems and PreferenceDialogItems have not been specified until now, but it is obvious for me that they should be offered by the kernel. (I would like to notice that the term "Extension" does not mean "plug-in" here, but if we have plug-ins, they could install themselves as extensions). Now I have to stop writing: I just do not have time for more now. 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
