Re: [Freemind-developer] FreeMind Design aspects
A premier mind-mapping software written in Java
Brought to you by:
christianfoltin,
danielpolansky
From: Ray B. <ray...@co...> - 2008-01-15 19:49:07
|
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 > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > |