Talk:Program design

Implementation of the Model View Controller pattern can be revisited

NOTE: Because of the way this reference is handled, the coupling between the model, the view, and the controller appears to be very high. I haven't finished going through it all, but it appears, to me, that there might be some benefit in reducing the size and complexity of these classes in order to reduce the coupling. High coupling (Calls back and forth between modules) can be a source of frequent bugs.

At the moment, it looks as if I might have to code up my own versions of Controller and MapView in order to create the preview pane for the redesigned Format Dialog. I might just still be confused. What I want to do, is to create a preview pane, essentially a JPanel, which can show how the formatting changes will look. Right now, it appears that with the current way things are done, all changes are made directly to the properties of the model. For my purposes, it would be better to be able to get a copy of the properties, let the user play with them, and then copy them back when, and if, the user hits the Okay button. (** Commentary **) - I use this tag to mark stuff I want to delete out later.

Rben13 12 Oct 2007

Each Mind Map requires its own MindMapController object

MindMapController implements interface ModeController which is responsible for creating and managing of mode-specific user interfaces and actions. Currently all those objects are created for each single map instance, which is not necessary. It makes implementing of multiple map views for each opened map difficult. It results also in additional costs for creation of the menus and actions for each single map.

Every Implementation of ModeController should become Singleton. The ModeController should get the actually active MapView from ModuleManager which manages currently active Map and MapView objects. This would make possible many MapViews instances for each Map.

DimitriPolivaev 10:18, 26 Oct 2007 (PDT)

Huge class MindMapController contains too many methods and too much code

Over sized MindMapController is one of the main short-comings.

• The file has about 2000 lines.
• The class contains many Actions as individually listed member variables and offers methods which actually belongs to the corresponding action classes.
• Some Actions are even implemented as its inner classes resulting in unnecessary dependencies between them
• Some methods like setNoteText(MindMapNode node, String text) are called only from Actions defined as Plug-Ins, but they do not belong to the plug-ins.
• The class was thought as a facade to the single actions, but it does not make sense as
  • there are too many actions,
  • The most actions must implement interface ActionListener and are directly called as reaction on user input events,
  • The plug-in defined actions called Hooks are also invoked directly, no additional Method is necessary either.

The class should be refactored as follows:

• "Internal" Actions should not be member variables of the MindMapController , so that no changes in MindMapController is necessary if actions are changed.
• The Methods relevant for the single Actions should be moved to the Actions.
• The Actions created by ModeController including the plug-ins build all together the real Controller. No Facade class should exist any more. The MindMapController should become a Factory.

DimitriPolivaev 10:18, 26 Oct 2007 (PDT)

OptionPanel should be improved for automatic including of plug-in configuration parameters

Main advantage of the plug-in mechanism in FreeMind is possibility of extending FreeMind without changing its kernel classes. This principle does not work for configuration parameters like hot keys: instead of describing the new parameters as a part of the plug-in description one extends private (!) Method getControls of class OptionPanel. The method already has ca. 750 lines.

The plug-in should become a way to declare their configuration parameters in their xml descriptors.

DimitriPolivaev 10:18, 26 Oct 2007 (PDT)