Hi,
I second this. We need to decouple the main classes for sure.
Thanks from Chris
Ray Benjamin schrieb:
>
> 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
>
-------------------------------------------------------------------------
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
