> So will TreeData replace TreeModel? Or will TreeData hold the state of > expanded/collapsed nodes as HtmlTreeNode does at the moment?
I am thinking that TreeData is a superclass for HtmlTree. This would be similar to how UIData is the parent class for HtmlDataTable. I still need to give some thought as to how to store the state of the expanded and collapsed nodes. There are some advantages to having the nodes be unaware of whether their own expand/collapse state. I would prefer to think of the node as a strictly a data container. It should have type information (to assist in rendering) and other nodes plus a description and id. That's it. Whether or not the node is expanded is really a "view" detail. I'm thinking that the renderer would keep track of the open and expand portion. That would seem appropriate because only the renderer really needs to know (so it can render outgoing HTML correctly.) Of course a *change* in the nodes expand/collapse state is important beyond the renderer. But that change in state could be handled by action listeners. > I guess you will iterate over the list of nodes visible in the tree > (meaning all the expanded nodes plus their respective children) but not > over all the nodes in the tree model. I see a need to refactor the way > the state of a tree is stored as the rendering using facets will be > different to how rendering is done today. If that's what TreeData is for > then it's ok to me but maybe a little bit confusing to the user: > "TreeModel? TreeData? What's the difference?" In my app at work we store the expand/collapse state in cookies. This way every time they click on a leaf and the tree is re-rendered, the same nodes are open as before. (If they don't have cookies no big deal, tree starts off closed again.) We probably can do better than cookies in the JSF version. I haven't thought it through all of the way yet. But this would be another reason to break the expand/collapse state away from the nodes. This information could be persisted seperately from the data model. Anyways, these are just some ideas. I am open to any suggestions/questions/critcism... > Oliver sean
