Oliver,
The rendering rule is an interesting concept. This idea (or a
variation of it) might work. I still find myself wondering if we
can't make this simpler by avoiding introducing these rules and
conditions into the mix.
Take this simple example:
<f:facet name="foo-folder">
<h:panelGroup>
<h:commandLink immediate="true" action="#{t.toggleExpanded}">
<h:graphicImage value="folder-open.png"
rendered="#{node.expanded}" border="0"/>
<h:graphicImage value="folder-closed.png"
rendered="#{!node.expanded}" border="0"/>
</h:commandLink>
<h:outputText value="#{node.description}" styleClass="nodeFolder"/>
</h:panelGroup>
</f:facet>
Now I know you mentioned that you are not wild about having info on
the nodes expansion state in the node. I thought the same thing but I
changed my mind slightly after thinking about it and reading up on
Bergsten's O'Reilly example.
What I've done so far is to have setExpanded and isExpanded as part of
the TreeNode interface. This makes the JSF *much* simpler to code,
plus you can take advantage of the existing rendered attribute which
is already well known to users.
The reason why I feel this is ok is because the end user only is
responsible for populating the nodes other data. They do not have to
(nor should they) specify the node expansion state.
In my initial pass of the HtmlTree code I store the expand/collapse
info in a HashSet that is part of the HtlmTree component. HtmlTree
calls setExpanded on each node before its rendered by checking this
information. You can continually update your data model on each post
(assuming its a request scope bean) and expand/collapse status of each
of the nodes is restored along with the component tree.
What do you think about this approach? I think it simplifies things
without requiring the node to maintain the expand/collapse info
between requests. These methods are just there to assist in
rendering. We could consider something along the lines you are
proposing but I am not sure it will be necessary.
sean
On Sun, 06 Feb 2005 15:26:32 +0100, Oliver Rossmueller
<[EMAIL PROTECTED]> wrote:
> Sean,
>
> I don't like to have information like if a node is expanded or not in
> the tree data. I was reflecting on that topic and following idea came to
> my mind: what about introducing a rendering rule component.
>
> <x:tree value="#{treeData}" var="node">
> <x:treeRenderingRule branch="true" expanded="true">
> <h:graphicImage value="open-folder.gif"/>
> <h:outputText value="#{node.description}"/>
> </x:treeRenderingRule>
> <x:treeRenderingRule branch="true" expanded="false">
> <h:graphicImage value="closed-folder.gif"/>
> <h:outputText value="#{node.description}"/>
> </x:treeRenderingRule>
> <x:treeRenderingRule branch="false">
> <h:graphicImage value="document.gif"/>
> <h:commandLink immediate="true" value="#{node.description}"/>
> </x:treeRenderingRule>
> </x:tree>
>
> This way we don't have to expose the expanded/collapsed state. And we
> can make the rules even more flexible:
>
> <x:tree value="#{treeData}" var="node">
> <x:treeRenderingRule branch="true" expanded="true"
> condition="#{node.locked}">
> <h:graphicImage value="open-folder-locked.gif"/>
> <h:outputText value="#{node.description}"/>
> </x:treeRenderingRule>
> <x:treeRenderingRule branch="true" expanded="false"
> condition="#{node.locked}">
> <h:graphicImage value="closed-folder-locked.gif"/>
> <h:outputText value="#{node.description}"/>
> </x:treeRenderingRule>
> <x:treeRenderingRule branch="true" expanded="true">
> <h:graphicImage value="open-folder.gif"/>
> <h:outputText value="#{node.description}"/>
> </x:treeRenderingRule>
> <x:treeRenderingRule branch="true" expanded="false">
> <h:graphicImage value="closed-folder.gif"/>
> <h:outputText value="#{node.description}"/>
> </x:treeRenderingRule>
> <x:treeRenderingRule leaf="true">
> <h:graphicImage value="document.gif"/>
> <h:commandLink immediate="true" value="#{node.description}"/>
> </x:treeRenderingRule>
> </x:tree>
>
> Logic is that a rule with a condition is evaluated before a rule without
> a condition, and rules with a condition are evaluated in the order they
> are defined. I guess most use cases can be handled this way, even the
> ones I need an IconProvider for at the moment.
>
> Oliver
>
>
> Sean Schofield wrote:
>
> >I wanted to start a new thread concerning some of the progress I have
> >been making with the new tree component.
> >
> >The first bit of news is that I discovered that Hans Bergsten, author
> >of the O'Reilly JSF book, has a fairly complete example of a custom
> >tree component. Its been simplified somewhat but it did manage to
> >solve a few of the problems I was grappling with. Also, it used a
> >similar approach to some of the ideas that I have proposed on this
> >list. I contacted Hans and he gave me permission to use portions of
> >his code in the new component.
> >
> >I've also given some more thought to how the JSF tags should work.
> >Here is a revised example.
> >
> > <x:tree value="#{treeData}" var="node">
> > <f:facet name="branch">
> > <h:panelGroup>
> > <h:graphicImage value="open-folder.gif"
> >rendered="#{treeData.nodeExpanded}"/>
> > <h:graphicImage value="closed-folder.gif"
> >rendered="#{!treeData.nodeExpanded}"/>
> > <h:outputText value="#{node.description}"/>
> > </h:panelGroup>
> > </f:facet>
> > <f:facet name="leaf">
> > <h:panelGroup>
> > <h:graphicImage value="document.gif"/>
> > <h:commandLink immediate="true" value="#{node.description}"/>
> > </h:panelGroup>
> > </f:facet>
> > </x:tree>
> >
> >The major change is that I've consolidated the "open" and "close"
> >graphic images into a single panel group. I've added a
> >getNodeExpanded method to the the TreeModel so that you can render the
> >appropriate image. I also enclose everything in the facet inside a
> >panel group. I discovered this was necessary after some testing (I
> >guess facet can only handle a single child).
> >
> >If you look at all of the options this gives you, it doesn't seem like
> >an IconProvider is necessary. You've go the "var" attribute which you
> >can combine with existing attributes like "rendered" and "disabled".
> >You should be able to use backing beans and/or subclass of TreeNode to
> >get all of the behavior that Oliver mentioned in his use case (locked
> >node, etc.)
> >
> >I personally like specifying the image file and location right on the
> >jsp page. I am not really wild about burying the details of the
> >images in some class somewhere. It seems like we could avoid this
> >with the solution I am proposing.
> >
> >I am working on an initial version of the tree to check in (see
> >earlier email on the dev list). It should be ready by the end of next
> >week. It will contain a very solid starting point for people to
> >evaluate and make suggestions. It probably will not have any of the
> >expand collapse features for another few weeks but it will be coming
> >shortly.
> >
> >I think this is going to be a sweet little JSF component. I already
> >know it works and looks great in its current incarnation as a Tiles
> >component. Now I am starting to get excited about how it will work in
> >JSF. Also, I am getting an increasing appreciation for how powerful
> >of a framework JSF really is.
> >
> >Looking forward to your feedback,
> >
> >sean
> >
> >
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>
