FreeMind refactoring plan

I propose following refactoring steps in order to improve FreeMind's architecture and design: see freeplane refactoring page. --DimitriPolivaev

Original proposal of refactoring

Keywords	Problem	Measure
Property packages	Over sized Model and controller classes, different features are implemented in these kernel classes instead of their own separate and lose coupled classes.	Split model and controller in multiple classes responsible for different node and map properties (node text, edges, clouds, icons etc). Put thess classes in different packages. Provide facade classes for the packages. The classes containing the actions should be specified in mindmap_menus.xml. Different packages should be introduced for: node formatting text formatting clouds edges icons attributes and so on.
Menu builder	Lack of menu building component. The job is done by different controller classes which makes the menu difficult to extend.	Introducing of menu builder (Design Pattern “Builder”) which can be accessed from all interested components during their initialization.
Undo handling	Using jibx for XML serialisation of actions requires extending of the one xml document “freemind.xsd” for generation of marshallers and unmarshallers. Plug-ins can not add their own properties to maps and nodes without extending this file if they want to define their own actions. Separation of action beans generated from this file from action code makes the code difficult to maintain and to understand.	Use of XStream library instead of jibx for XML – Serialisation. Move action data into actor classes and let XStream do the rest.
Application classes	Application initialization and building of application frame including tabbed panewith the map tabs, , scroll pane, split pane and so one is implemented in one class FreeMind which also extends JFrame.	Move application initialization logic and tab management into new classes.
OSGI	Very complex extension mechanism (Hooks) with long class inheritance hierarchies.	Use extension objects pattern for model and controller. When model and controller should not depend on the property packages. Replace current Hooks by OSGI plug-ins directly extending controller and model classes via Extension Object pattern.
Preferences pane builder	Almost elements of preference dialog set up in a single place.	Introducing of property editor builder (Design Pattern “Builder”). The same bilder can also be used for building formatting dialogs.
Map loading and saving.	FreeMind specific code introduced directly into XML parser XMLElement. Mixing of XML parsing logic with freemind logic makes code difficult to understand. Loading and saving of map and node properties should be implemented in property packages, not at the central place.	New class NodeXmlElement extending XMLElement should contain freemind specific issues. .load(XMLElement e) methods symmetric to existing .save(XMLElement) methods should be created.
Models overloaded by loading and saving code.	Saving and Loading code belongs to model classes instead of controller classes. This leads to different model classes for browse and mind map editing modes.	All .load and .save methods should be moved from model to controller classes. So the model classes of browse mode and of mind map editing mode become identical, there are only differences between controllers.