Sean Schofield wrote:
So will TreeData replace TreeModel? Or will TreeData hold the state of expanded/collapsed nodes as HtmlTreeNode does at the moment?Oliver,
I am starting to work on some of the new classes (and changes to existing classes) for the Tree.
I was wondering if we really need the stuff concerning TreeModelListener. I'm imagining this would be a server-side implementation rquirement but I still can't figure out why we would need it.
I am planning on adding a new class TreeData (similar to UIData). The plan is that It will iterrate over the entire list of nodes and ask the renderer to render the node based on the matching facet. The dynamic changes to the data model would happen before the RendersResponse phase so I'm thinking that the tree does not need to worry about whether or not the model has changed. Its going to render whatever is in the model at that time.
What do you think about this approach?
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?"
Oliver
sean
On Tue, 01 Feb 2005 22:10:40 +0100, Oliver Rossmueller
<[EMAIL PROTECTED]> wrote:
In fact the tree was created with the swing tree component in mind as might also be stated somewhere in the comments of the sources. In fact the myfaces TreeNode interface is a clone of the swing TreeNode interface. Reason is that I did not like the idea of having myfaces depend on swing because of that interface.
And to answer the question why children() returns an Iterator and not an Enumeration: well, I prefer Iterator because of it's interface which I know from other languages. There is no deeper reason than that. If you like I'm just following the Enumeration javadoc: ' New implementations should consider using Iterator in preference to Enumeration.' :-)
Oliver
Heath Borders wrote:
I'm in favor of using the Swing TreeNode interface. I'd really like to see this whole thing implemented exactly like the swing JTree with the models they have.
On Sun, 30 Jan 2005 12:08:54 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote:
One revision to my suggestion would be to not have a separate interface for branch vs. regular node. We can probably use the existing MyFaces TreeNode interface which has an isLeaf method. It turns out this is how its done in the Swing version of TreeNode so we should probably conform to that.
One question for Oliver would be why the children() method returns an Interrator instead of Enumeration as in the Swing version? Other than this method the TreeNode interface seems to match the Swing version.
Also, would it be appropriate to just use the javax.swing.tree.TreeNode interface? If the interfaces are identical maybe we could just use the one in the java API. Its a little odd perhaps but I can't really think of a good reason not to do so.
sean
-- Oliver Rossmueller Software Engineer and IT-Consultant Hamburg, Germany http://www.rossmueller.com
-- Oliver Rossmueller Software Engineer and IT-Consultant Hamburg, Germany http://www.rossmueller.com
