 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / GUI / October 2005can JTree's have multiple roots and models ?
I want to change my tree around and I have the following questions about a JTree? - Can a JTree can have several root nodes? - Can a JTree have several TreeModel's for each root node? Thanks, >I want to change my tree around and I have the following questions > about a JTree? > > - Can a JTree can have several root nodes? > - Can a JTree have several TreeModel's for each root node? I suspect the answer is "no" to both, but I'm not sure. Have you considered taking all your trees, and making them children of a so-called "super root", and then using that as the root of the JTree? Similarly, take all your TreeModels and make them children of a "super-TreeModel", and make that the model for your JTree. - Oliver > I suspect the answer is "no" to both, but I'm not sure. > > Have you considered taking all your trees, and making them children of a > so-called "super root", and then using that as the root of the JTree? I currently have this, but my tree is getting too deep and everything stems from one main root node. I'd like to take some of this wasted space/level off. Maybe I can just hide the main root node and just show the children. > Similarly, take all your TreeModels and make them children of a > "super-TreeModel", and make that the model for your JTree. > > - Oliver Not sure I follow this idea, I didn't think models could have models, unless you meant to make my own super model to manage it's children models. >> Similarly, take all your TreeModels and make them children of a >> "super-TreeModel", and make that the model for your JTree. [quoted text clipped - 4 lines] > unless you meant to make my own super model to manage it's children > models. I meant you could have a main "super" TreeModel delegate most of the work to your other TreeModels, with the super TreeModel mainly dealing with creating the illusion that all of those sub-models are part of a bigger tree. Here's an example implementation: <code> public SuperTreeModel implements TreeModel { private final ArrayList<TreeModel> subTreeModels; public SuperTreeModel(ArrayList<TreeModel> subTreeModels) { this.subTreeModels = subTreeModels; } public Object getRoot() { return this; } public Object getChild(Object parent, int index) { if (parent == this) { return subTreeModels.get(index).getRoot(); } /* Otherwise you have to figure out which TreeModel the parent came from, and then delegate the call appropriately. You might have to have control over the subTreeModels to do this, and add a "containsNode()" method in them. */ } /* Etc. for the other methods. */ } </code> - Oliver > I meant you could have a main "super" TreeModel delegate most of the > work to your other TreeModels, with the super TreeModel mainly dealing with > creating the illusion that all of those sub-models are part of a bigger > tree. Here's an example implementation: When layering models like this, you need to be careful with listeners. You should make sure when the model nearest the component has no listeners attached to it, it has no listeners attached to the underlying model(s). If you don't, you might find yourself with a small (or otherwise) memory leak. Tom Hawtin  SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >> I meant you could have a main "super" TreeModel delegate most of the >> work to your other TreeModels, with the super TreeModel mainly dealing [quoted text clipped - 6 lines] > If you don't, you might find yourself with a small (or otherwise) memory > leak. I'm guessing the easy fix for this would be to have your "super TreeModel" register listeners on all of its sub TreeModels right away, and then never fiddle with the listeners from there on. Then, the super TreeModel receives an event from one of its sub TreeModels, it just forwards these events to its own registered listeners. Would there be any problems with this implementation? - Oliver >>When layering models like this, you need to be careful with listeners. You >>should make sure when the model nearest the component has no listeners [quoted text clipped - 9 lines] > > Would there be any problems with this implementation? The problem is you have (strong) references set up as below (the upper arrows represent the references via listeners typically implemented as inner classes of some description). <------ <------ JTree Composite model Underlying model ------> ------> The JTree and composite model are all about a single display. Suppose the underlying model is longer lived. Removing the composite model from the JTree should free up all the required memory, but you end up with: <------ JTree Composite model Underlying model ------> The composite model (and anything it refers to) is not collectible. However if you composite model only adds listeners when it has listeners applied to itself, then you get: JTree Composite model Underlying model ------> The composite model is now collectible as it should be. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >>>When layering models like this, you need to be careful with listeners. >>>You should make sure when the model nearest the component has no [quoted text clipped - 17 lines] > JTree Composite model Underlying model > ------> ------> I don't understand what you mean by inner classes. For now I'm assuming this has something to do with Sun's implementation of listeners that you know about and I don't, because the way I understand it, the subscriber does indeed initially need a reference to the observed object to subscribe to it, but it can then forget about that reference. The observed object, simply needs a list of references to all items subscribing to it; when no one is subscribing to it, that list is empty (i.e. it doesn't have references to any other object). (I'm also not sure I understand the significance and distinction between the upper and lower arrows). > The JTree and composite model are all about a single display. Suppose the > underlying model is longer lived. Removing the composite model from the [quoted text clipped - 5 lines] > > The composite model (and anything it refers to) is not collectible. I thought Sun's garbage collection algorithm had something to do with whether the objects were reachable from live code. Assuming the composite model and the underlying model don't have any threads looping in one of their methods, once the thread -- the one that told the JTree to unsubscribe from the composite model -- leaves the scope of the JTree, the composite model and underlying model will no longer be reachable, and thus be collectible. - Oliver >>>>When layering models like this, you need to be careful with listeners. >>>>You should make sure when the model nearest the component has no [quoted text clipped - 19 lines] > > I don't understand what you mean by inner classes. http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.3 Listeners are implemented as inner classes the vast majority of the time. Often anonymous inner classes. > For now I'm assuming > this has something to do with Sun's implementation of listeners that you [quoted text clipped - 4 lines] > subscribing to it, that list is empty (i.e. it doesn't have references to > any other object). In the case of listening to input events, that's true. If I have an action listener, there is no further information necessary to perform the action. In some circumstances you might want to reduce the class count and use the event source to distinguish between a series of actions. In the case of listeners to state change events, there isn't enough information to do anything useful. If you want to repaint a tree, you need to go back to the tree model and get values for each of the showing nodes. You also need a reference to the observed object in order to remove the listeners. > (I'm also not sure I understand the significance and distinction between > the upper and lower arrows). The leftward (upper) arrows represent an indirect strong reference, via a listener, from the observed/publisher/event source to the interested object. The rightward (lower) arrows represent the direct strong reference from the interested object to the observed/publisher/event source. >>The JTree and composite model are all about a single display. Suppose the >>underlying model is longer lived. Removing the composite model from the [quoted text clipped - 13 lines] > model and underlying model will no longer be reachable, and thus be > collectible. Often the underlying model will have a longer lifetime. If this is the case, then the observing model will still be strongly reachable, after it has server its useful lifetime. Memory leak. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > Maybe I can just hide the main root node and just show the children. You are looking for JTree#setRootVisible (see [1]), don't you? Markus [1] http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JTree.html#setRootVisible(boolean) >> Maybe I can just hide the main root node and just show the children. > > You are looking for JTree#setRootVisible (see [1]), don't you? > > [1] > http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JTree.html#setRootVisible(boolean) Note, you need to make sure that the root is always open, even after updating the tree model. If it isn't, the user can't see the (model) root node to open the display of apparent root node. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.