> 1 - Being able to add/remove nodes on the fly. > Currently I think doing things like changing the > text of a tree node works (does for me, anyway) > If you setup an example of how to do this, you'll > quickly see the problems.
What do you mean by "on the fly?" At what point are you wanting to add/remove the nodes? AFAIK this can be done although there are some issues with clicking on a node that doesn't exist anymore, etc. Those are minor bugs and I will fix them shortly. In general, you can add and remove nodes as the result of click events, etc. > 2 - Selecting a node from the model. People want to have > a wizard which adds a node to the tree & they want to > have it automatically selected. Being able to > arbitrarily select any node in the tree, from twiddling > the model (and also have the path to it expanded) is a > very real use-case. Yes I know this is important to some people. I will try to work on this when I get a chance but it is a lower priority for me right now than some of the other JIRA issues and general documentation. I've asked a fellow programmer (Matt Blum) who is working with me on a new JSF control (inputSuggest) to help out if he has a chance. One option that I have thrown out there before is to make TreeModel an interface (and change the current TreeModel class to DefaultTreeModel.) Then allow the users to supply their own TreeModel. Its not clear whether the node selection and expansion should be part of TreeModel or not. If we start to move all of that into TreeModel then what is left for HtmlTree to do? At some point it might just make sense to subclass HtmlTree instead of writing your own TreeModel. Some on this list have already done this. I will need to study the issue more closely before I reach my own conclusion on that. > -- Jon sean
