This is exactly the kind of discussion I think needs to happen before a
design is settled on.
As Christian points out, Facades are usually quite large. The question
becomes, is there unneeded functionality in the MindMapController that
should be moved out of it?
The biggest problem I've run into, when trying to create the new format
module, is that I can't create an independent MindMap because of the
interrelationships between so many of the top classes. It might be best
to think about taking the refactoring in steps.
The current design has served for some time. It has problems:
* You can't have 2 models open and displayed at the same time.
* High cohesion between modules makes it easy to introduce bugs -
the same cohesion makes it harder for new programmers to learn the program.
* It is difficult to add new features to the program.
* Groovy, our chosen scripting language, has universal access to the
code, so it presents as security risk.
I'm sure there are others that the rest can come up with. Perhaps we
need to identify the areas that are causing us the most grief, and use
those to guide us in choosing an appropriate design.
Ray
Christian Foltin (GMX) wrote:
Hi Dimitry,
the longer I think about your proposal, I see that it is contratictory
to what I has as goals in my development and what I want to achive.
So here some more comments:
* Who says, that a small kernel is the right for an application
like FreeMind? Only as the linux kernel is built like this?
* 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.
* 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.
* 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.
* 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.
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.
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
-------------------------------------------------------------------------
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
