Any news for this patch? Any chance this should be included into a nightly builds before release 1.1.1?
 
Thanks

Nicola
 
On 9/28/05, Mathias Werlitz (JIRA) <[email protected]> wrote:
   [ http://issues.apache.org/jira/browse/MYFACES-568?page=comments#action_12330672 ]

Mathias Werlitz commented on MYFACES-568:
-----------------------------------------

I'm not really up-to-date with the release of 1.1.1 but I think this patch should be included ... it will save us a lot of illogical state exceptions

> tree2 TreeState wrong after node deletion/reposition, causes Servlet Exception
> ------------------------------------------------------------------------------
>
>          Key: MYFACES-568
>          URL: http://issues.apache.org/jira/browse/MYFACES-568
>      Project: MyFaces
>         Type: Bug
>   Components: Tomahawk
>     Versions: 1.1.1
>  Environment:  Tomcat 4.1.31, SDK 1.4.2, windows XP Pro
>     Reporter: Bett Koch
>  Attachments: tree2_bitmask.txt
>
> We are using the tree2 component in a situation where nodes can be dynamically added, deleted and re-parented.
> The tree can also be completely re-populated with a different version of data.
> We have also simulated multiple node selection, by placing a checkbox
> next to certain nodes. Clicking a button then causes bulk-deletion of all ticked nodes.
> We were using the myfaces 1.0.9 version in this way:
>
>       <t:tree2 value="#{xxx.treeData}"
>                var="n"
>                varNodeToggler="tn"
>                clientSideToggle="false">
>
> The backing bean is in Session Scope; treeData was a TreeNode.
> All this was basically working, with the exception of a refresh problem after a re-population (reported in MYFACES-404),
> and a problem whereby you had to click twice to expand the root node when the page first displayed.
> We want to migrate to the nightly builds, in which these two issues are fixed (thanks!)
> But we hit problems with the new TreeState: (using nightly build of 11-Sep-05)
> 1. When moving to another page and then coming back, the tree is always collapsed.
> 2. When re-populating the tree with a different data set, OR
> 3. When deleting or reparenting a node, often this kind of error (eventually) occurs:
>       javax.servlet.ServletException:
>       Encountered a node [0:4] + with an illogical state.
>       Node is expanded but it is also considered a leaf (a leaf cannot be considered expanded.
> By reading thru the various postings and forums I have fixed:
> 1 by creating our own TreeModel and value-binding to that (rather than a TreeNode)
> (Incidentally, adding a component-binding, ie <t:tree2 binding="#{xxx.treeComponent}" value="#{xxx.treeNode }"..>
> also fixed the problem without using our own TreeModel)
> 2 by setting the Transient property of our TreeModel's TreeState to True
> (which I understand is OK since our backing bean is session-scoped)
> But I can't figure out 3.
> How can you fix up the TreeState after programatically causing nodes to change positions or disappear,
> since the TreeState maintains its node expansion knowledge via a Hashmap keyed on positional node ids
> (0:1:4, etc).
> As a work-around I've thought of collapsing any node (and its subnodes) before trying to delete or move it, or even
> collapsing the whole tree, but I can't work out how....
> UITreeData only gives you the nodeId of the 'current' node, so I don't understand how you get at
> nodeIds of arbitrary nodes to feed to the new collapsePath() method.
> (Incidentally, maybe a collapseAll() method might be useful to have as well as expandAll()?)
> Thanks for any help, and please set me straight if I've misunderstood anything about the changes made to tree2 along the way!
> Regards, Bett

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
  http://www.atlassian.com/software/jira


Reply via email to