First, let me say thank you for writing this component. My team and I are building a userid / resource provisioning system encompassing over 30 distinct classes of systems (loosely defined as something which requires a userid). Each system (or class of system) maps to a node of the tree. Under each of these nodes is an appropriate set of sub-nodes and controls, either a datatable or checkboxes in a grid with labels and sometimes inputText, each of which maps to a resource. The end user will navigate the tree, selecting and deselecting resources to add to, or subtract from, the user of interest. We have also implemented a "copy from" function which fills in the tree with the current set of selected systems/resources.
Now, while you may have not envisioned this support, you didn't tell me not to do it. So I did. And it works, rather well actually, to solve the problem at hand. I'm not sure how I would have done this project without it. I hope you can see, for this use case, why client side tree is important, and why I need to process the closed nodes. The form is very large, making the round trip delay with server side toggle unacceptable. Also because the form is very large, with many nodes and sub-nodes, the end user will naturally a) open a node of interest; b) select some items; c) close it; and d) repeat for another node. I must simply disagree that it is impossible to "do anything meaningful" to a closed node. As you can see, I am doing just that. Perhaps it would it be possible to add a parameter, "processClosedNodes", or something, to save the processing time for those who do not need the support? With all of the above in mind, I will find some time this weekend to submit a bug report, and let it go through the process. If it is decided not to fix it, I will simply have to keep the source modification in my own implementation. An ajaxian solution would be interesting indeed. . . Thanks for your continuing good work, Dan -----Original Message----- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Friday, December 09, 2005 10:40 AM To: MyFaces Discussion Subject: Re: Tree2 with clientSideTogle does not process collapsed nodes 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. >
