Resamp,
One of the things we want to be careful of, when we refactor FreeMind,
is that we don't try to add a bunch of new things at the same time. The
idea behind refactoring is that you improve the code base without
altering the behavior of the program. That way, we can verify that we
haven't broken anything by comparing the behavior of the refactored code
against the original code.
That doesn't mean we can't build the design so that we can do things
like support multiple documents open at the same time, but we shouldn't
actually take advantage of that feature until after the refactoring is
complete.
Thanks,
Ray
Reasamp wrote:
Now after years of doing the right things (in sense of features) I see a
chance to get the things right and easy (in sense of design). As you
see, the most important idea of the proposed design is a concept of
independent extension packages implementing independent map and node
properties and seamlessly integrated into the framework.
Yes, this is the part of all major changes as I can see. But, didn't get
the time to go very thoroughly into this yet, so I'll have more to say
later; but to start with, where are you drawing the line between an
"extension", and just a "visitable" object? What "visitable" objects are
you thinking other than "extensions"?
* Seems ApplicationController can have only one instance of
FreeMindContainer. Maybe we could share one ApplicationController over
many FreeMindController, [...] Might help a few synchronization
problems between user preferences [...]
I like your idea. Although it is beyond the pure refactoring, we could
keep it in mind and implement it later, may be after the refactoring is
finished.
Are you planning to go into a refactoring phase before this new design is
implemented? Because I think small things like these can often create an
extremely buggy solution if implemented later on, and I dont want to see
this project get there. Whatever we decide, I prefer to have that decision
early on and then stick with it from the very onset. I'd prefer if we
either decide to disable multiple windows/application instances altogether
(that would be simpler to do), or we decide to fully support it (what I'd
personally prefer) from the very point we start coding by this design.
* FreeMindContainer#isApplet() - [...] a similar but more genericmethod
could be added here as well,
isOfType(String). I know this is basically the same as invoking
reflection
on 'this', but for the sake of completeness it feels like it might have
a place here.
[...] Let us remove
this method for now.
Removing wasn't exactly what I meant, but yes, let's see what we actually
need.
Could be done later.
I can remove both ModeController#getActiveMap() and
ModeController#getActiveMapView(), because they rather belong to the
ApplicationController (and they are already present there).
O, ok ... I somehow still can't find it in ApplicationController. Could
you give me the exact method name?
* Usually, the close() method of a resource comes with the class
representing that resource. [...] (like File objects have a close
method, NOT a System.close(File) method). So it seems more intuitive to
me
that Map create/load/save/close methods should be in the MindMap class.
[...] I know this would probably mean they simply wrap the
corresponding calls in a ModeController, but it reduces the need for a
ModeController object to be exposed in areas where it could be treated
as
an implementation details hidden inside a MindMap, simplifying codes.
I am not sure whether the MindMaps containing the model should be
provided with strategies of how those models are created, loaded or
saved. [...]
Right :-) Actually I realized this part when I was done writing the first
half, so I went on to add the 2nd half saying that such calls in MindMaps
should probably just wrap the ones provided by ModeController.
Although redundant, I see it's value as clarifying the API. I mean if I
want to create new maps, or load them, I'd probably go looking for them in
the MindMap class. Similarly, if I want to save a map, a map.save call
would make a lot of sense. But something like
map.getModeController().save(this) would mean I'd have to go through
ModeController API, and nothing in the MindMap method list would tell me
that something by the name of 'getModeController' would actually let me
save this map. And even then I would be unsure about calling it, since I
wouldn't know if this was in fact the right method or is it supposed to be
an internal method meant to be called by some other method "really" meant
for the saving purpose. At least this *is* the kind of problem I first
faced a few days back when I joined in this project. Just a few wrappers
providing a more conventional interface would have made things easier on
me.
Reasamp
-------------------------------------------------------------------------
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
