> 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
