> I would merge the x:tree and x:tree-config like
>
> <x:tree value="#{treeData}" var="node">
>
> ...
>
> </x:tree>
>
> as I can not see the advantage of another level of nested tags. But I
> like the idea of using facets so you can create a custom presentation of
> your tree nodes.
I can see the argument for merging the two as you propose. The reason
why I was thinking about nesting was so that you could customize the
look and feel of certain nodes without having any information in the
node to go by.
I was thinking that this would be cleaner because for the model there
is really no reason to differentiate a "folder" branch from a "person"
branch. On the other hand, the problem with my approach there is that
you are assuming a certain structure to the tree in your presentation
layer (ie. the first branch will be a person, the next level below
that will be a folder, etc.)
I'm glad you like the facet idea. I think that will be a logical way
to configure the tree.
{snip}
> But this way the data has to know how it will be represented in the user
> interface, so actually that's not an option to me.
Same problem for me.
> The current tree implementation already offers an interface called
> org.apache.myfaces.custom.tree.IconProvider to deal with the requirement
> of different node icons. In case an icon provider is specified the tree
> renderer will ask the provider for the image url of any node displayed
> in the tree. This is a very simple but flexible way to specify icons.
Interesting. I will have to look some more at your IconProvider class.
> I hope you get the idea.
Yup. I agree with you about the losing the <x:tree-config> element
and just using the facets within <x:tree>. I have some more ideas in
response to the email but I will send separately because its hard to
do inline comments with both of our code examples in the same email.
> Oliver
sean
