TreeNode getRoot() instead of
Object getRoot()
).
So I don't see why there would be a requirement for defining the data hierarchy inside x:tree tags, that's what the model if for. And - yes, I know I'm repeating myself :-) - for requirements where the node icons depend of complex logic IconProvider was introduced.
Oliver
Sean Schofield wrote:
Heath,
I think that most cases will be covered by the scheme I am proposing. Ultimately I think it will be hard to implement any kind of tree if
you are unwilling to put your data into some sort of TreeNode
interface.
I see you are using things like #{root.children} and #{child.text}. So you are assuming a structure where your root node will have a
getChildren method and that the children themselves will have a
getText method. Well between these two methods alone you have about
50% of the TreeNode interface! I guess I just don't see what is so
restrictive about specifying an interface. Ultimately you need to
pull data out of database, director server or whatever. You will need
to stash that data somewhere so that it can be rendered so why not
just use tree nodes?
Also, there will be some difficulty in implementing the component internally if you cannot assume an interface. Don't forget that the component is going to have to iterrate over all of the data during encoding/decoding, etc. This will be more difficult if you cannot assume basic functionality guaranteed by an interface.
I remain open to your ideas on this but I see some potential problems. Take a look at my example in the next day or two (when I post it) and let me know what you think. I think you will find it to be pretty flexible.
sean
On Thu, 3 Feb 2005 10:00:28 -0600, Heath Borders
<[EMAIL PROTECTED]> wrote:
The design you proposed is reflected in the <x:recursiveTreeLevel /> tag. I'd just want a simple way to define each level.
We actually get very good client-side performance from our trees, its the server-side memory that's the problem. We might be forced to go to a server-side tree just to solve that issue, however I'd really like to move away from a TreeNode interface since that can cut memory constraints in half. Additionally, the disconnectedness of the datamodel is closer to the way users are used to interacting with other JSF components.
On Thu, 3 Feb 2005 08:50:18 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
The reason that I'm still a bit opposed to this kind of layout is that
the way I'm currently using trees is to have different requirements
for each layer in the tree's hierarchy. That is, different icons at
different levels, and different nodes being enabled or disabled.
This is what I was initially proposing but I have since backed off that slighly because its such a pain to configure at each level in the JSF when a little bit of metadata (in the TreeNode interface) could simplify things greatly for you!
We currently have a javascript-based tree we are using, but it
requires that we rebuild our internal data structure into the
tree-data structure. Our models cannot be tied to the tree,
unfortunately (this means they cannot implement a TreeNode interface),
and ideally, we would like to not have to recreate our entire model
hierarchy in tree nodes because this effectively doubles the data
size, and generally our data sets we are displaying with the tree are
fairly large (> 500 nodes).
Just curious but why couldn't you implement the tree node interace? Are you using a tree for this data now? If so, then presumably you are building some sort of data structure with a node hierarchy. I would think you could just replace what you are using with TreeNode.
As for 500+ nodes, it sounds like you'd probably be more interested in the server-side variant of the tree. More than 500 nodes and you'll probably want to do a post each time a node opens right? (Javascript will always be possible but at a certain size, it will be prohibitively slow.)
What this means for me is at a bare minimum I'd need to have different
logic for each layer of the tree. Obviously, for trees that do not
have a pre-defined depth, it would also be best to allow all branches
to be defined in a given way, and all leaves to be defined in a given
way, as you are doing now.
A lot of the times you will probably only require one configuration for all branches and leaves. I think the configuration scheme I am proposing works well for that. Also, it works well for when the tree has arbitrary numbrer of levels to it but you still want to configure certains types of nodes to look a certain way.
Here is the type of JSP I would be looking for, for this type of
functionality. The example below illustrates the use of the tree with
a backing data model that is three levels deep. Each level can be a
POJO that contains an arbitrary property that binds to a Collection
(or a List if we are doing selections), of children. By defining the
levels recursively within one another, we can render the tree without
having to build an explicit data model. Additionally, this approach
could have two <x:treeLevel />'s as siblings, which could produce two
sets of TreeNodes with different renderings on the same level of the
tree.
[snip]
Let me think about your counter-proposal some more. I definitely can see where you are coming from because this was initially what I thought I needed as well. It turns out I was able to scratch my own itch with a simpler design.
Perhaps we can offer two variants of the tree or two variants for configuration... I will report back once I've had time to analyze your ideas.
-Heath Borders-Wing
sean
-- -Heath Borders-Wing [EMAIL PROTECTED]
-- Oliver Rossmueller Software Engineer and IT-Consultant Hamburg, Germany http://www.rossmueller.com
