where are you drawing the line between an "extension", and just a "visitable" object? What "visitable" objects are you thinking other than "extensions"?
I think on viewer components registered by extensions at NodeView's content pane. They should not be referenced by their class name. That's why many elements of the same class can belong to the same VisitableCollection. (If want we have multiple views for one map, we are likely to have multiple viewers per node and extension property).
Example (you see that I have changed the interfaces a bit, the new class diagram is attached to the mail. Further I have added a method MindMapNode NodeView#getNode())
public class AttributeExtensionController implements NodeViewLifeCycleObserver{
public void nodeViewCreated(ModeController controller, NodeView nodeView) {
MindMapNode node = nodeView.getNode();AttributeTableModel nodeAttributes = (AttributeTableModel)node.getExtensions().get(AttributeTableModel.class);
if(nodeAttributes == null){
return;
}
AttributeTable attributes = new AttributeTable(nodeAttributes);
nodeView.getContentPane().add(attributes);
node.getObservers().add(attributes);
}
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.
I would like to make as small steps as possible. I do not believe in final design, I believe in iterations. And I am no sure whether we should introduce additional complexity right now. IMHO after the refactoring is done, further changes can be introduced easier than now.
>> I can remove both ModeController#getActiveMap() and
O, ok ... I somehow still can't find it in ApplicationController. Could you give me the exact method name?ModeController#getActiveMapView(), because they rather belong to the ApplicationController (and they are already present there).
I mean methods getSelectedXXX() and setSelectedXXX(...). (I have intentionally used other name for stimulating a discussion about what name is better: getActiveXXX() or getSelectedXXX() .
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.
Agreed. Dimitry
<<inline: Extensions.png>>
------------------------------------------------------------------------- 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
