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]
