> * Where is the problem that the MindMapController is long? It is a
> facade (see GOF) and offers all possible actions on the model in a
> reliable and undoable way. So, it is clear that every change
> action like setBold and setText is done via the MindMapController
> derived from MindMapActions.
> This is design by purpose as it is now clear what to do to change
> the map. Before, this was difficult and the change methods were
> spread all over the application.
> The facade would be removed by your design proposal.
My design proposal replaces one oversized controller by many independent
property controllers which are easier to understand and to maintain.
They could be facades for their packages.
> * Who says, that a small kernel is the right for an application like
> FreeMind? Only as the linux kernel is built like this?
Linux, Eclipse and many other IDEs and other programs are developed in this
way.
Specifically for FreeMind: because Model, Controller and View for each single
property like icon or node text are coupled stronger than e.g. Modells or
Actions for differen independent properties, the splitting of the whole into
independent parts can be done bewteen the properties themselves.
> * An empty interface for extensions means that the main program
> can't help the extension to achive its goals. The extension is
> completely alone and responsible to do every work needed for it.
> This contradicts my main goal, that it should be easy to write
> extensions and that the main application should do the standard
> work like registering at the menus and to give signals, when
> important things happen.
The Kernel should send only common property independent signals, see y previous
mail for more.
> * I tried to make the MindMapController smaller by taking a map with
> String->Action pairs. But every access involved a casting then and
> I rolled the changes back.
The Castings and Access to Actions could be capseled in the property
controllers e.g.
Action IconController#someIconAction;
void IconController#setStateIcons(MindMapNode, MindMapIcon);
> * I started to implement the storage of notes inside the plugin.
> Later, I saw that a lot of places need to change or to read the
> notes texts and it was absolutely clear, that the notes content
> must be available for everybody in the public model.
> You are about to remove the items from the model. Thus, they are
> not so easy to access.
The access to the Note were as easy as
String NoteController.getNoteText(MindMapNode node)
{
Note note = node.getExtensions().get(Note.class);
return note != null ? note.toString() : null;
}
> So, let me state again my design goals:
>
> * It should be absolutely clear, how to change items in the model.
> * It should be easy to implement extensions. Extensions typically
> combine existing functionality in new ways users need them.
> * It should be clear, how things/responsibilitys are divided. (Like
> now, as the MindMapController is responsible to change/store the
> model and the model is responsible to hold it).
>
> Summarizing, I see it very critical to have such a generic design setup
> as you proposed.
All your goals can be achieved by the proposed design.
Dimitry
>
> Best regards, Chris
-------------------------------------------------------------------------
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
