Its been a while since I wrote those lines and I don't have the source
right in front of me, but I'm not sure this is a bug. Why would you
need to process something for a closed node on a client-side tree?
For client side tree I envisioned only a simple tree with command
links as your nodes. I didn't really envision support for checkboxes,
etc. Its already pretty complicated keeping the client side
expand/collapse changes in sync with the server copy. I guess you are
thinking that the checkboxes or whatever would be server-side toggle
and only the node expansion would be handled without a server post?
The problem with your proposed solution is that it will make the tree
much more inefficient on the server side. Its impossible to do
anything meaningful to a node that is closed after all. So why go
through 100% of the nodes when only the open ones need to be checked.
Large client side trees are also slow in IE (Firefox is much faster.)
I think the best solution in this case is an ajax-based tree. I'm
working on some ideas for that. First off though I'm trying to work
with Mathias on a TreeWalker interface to allow for dynamic trees. My
thinking is that with an ajax tree you can signal the renderer that
you just want a certain portion of the tree rendererd (which will be
very fast) and each ajax post will also update the expand/collapse
state (solving your problem.)
sean
On 12/8/05, Daniel W. Gerard <[EMAIL PROTECTED]> wrote:
>
> Background:
> We are using a dynamically-built tree2 component as a "resource selection"
> page.
> There is either a datatable with a checkbox column or an outputText/checkbox
> with a custom value binding at each leaf node of the tree.
> The tree is getting quite large, so clientSideToggle="false" causes an
> unacceptable delay while processing the page.
>
> Problem:
> With clientSideToggle="false" all works well. The model is updated with the
> appropriate booleans set or unset as (de)selected by the user.
> With clientSideToggle="true" the model is only updated for the nodes which
> are left expanded. Collapsed nodes are left in the state that they were in
> when the page was rendered.
>
> My fix:
> I built the project from source (tag 1_1_1) and started investigating. It
> took not too long to find:
> org.apache.myfaces.custom.tree2.UITreeData.processNodes (504)
> if(isNodeExpanded())
> {
> processChildNodes(context, node, processAction);
> }
>
> Removing the if statement fixes the problem. The tree behaves as desired
> (and expected?).
>
> It would seem quite odd if I were the first person to run across this,
> although I searched the lists to no avail. Is there something simple (an
> option or parameter) I have missed? Was the component designed to work this
> way? Am I likely to encounter any side effects from this? Should I file a
> bug?
>
> Regards,
> Dan Gerard
>
>
> Disclaimer: This e-mail message is intended only for the personal use of
> the recipient(s) named above. If you are not an intended recipient, you
> may not review, copy or distribute this message. If you have received this
> communication in error, please notify us immediately by e-mail and delete
> the original message.
> This e-mail expresses views only of the sender, which are not to be
> attributed to Rite Aid Corporation and may not be copied or distributed
> without this statement.
>
