Talk:Program design: Difference between revisions

From FreeMind
Jump to navigationJump to search
No edit summary
 
Line 28: Line 28:


The plug-in should become a way to declare their configuration parameters in their xml descriptors.
The plug-in should become a way to declare their configuration parameters in their xml descriptors.
[[User:DimitriPolivaev|DimitriPolivaev]] 10:18, 26 Oct 2007 (PDT)
[[User:DimitriPolivaev|DimitriPolivaev]] 10:18, 26 Oct 2007 (PDT)

Revision as of 17:19, 26 October 2007

Implementation of the Model View Controller pattern can be revisited

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)