[ 
http://issues.apache.org/jira/browse/MYFACES-621?page=comments#action_12330564 
] 

Mathias Werlitz commented on MYFACES-621:
-----------------------------------------

This issue is NOT related to MYFACES-580 ... its related to the changes of 
MYFACES-564

The problem is, that UITreeData does only process the child nodes (and their 
decoding) in processDecodes -> processNodes() if the parent node was expanded.
Now, in client side mode HtmlTreeRenderer sync the tree state in decode() with 
the data of the cookie ... only if preserveToggle="true" (default). But decode 
is processed AFTER processDecodes in UITreeData ... thus the tree state does 
not know about the new expanded nodes and does not process decoding for the 
childs (with the mentioned not working commandLink). On the next request things 
work fine because the state was updated in the previous request.

The sync has to take place earlier ... BEFORE UITreeData.processNodes() but 
this is not possible in a Renderer. AND sync has to be forced regardless of 
preserveToggle ... this would make it impossible to turn of preserveToggle?!

...I dont have a real solution for this right now.

> Tree2 commandLink not firing until second click
> -----------------------------------------------
>
>          Key: MYFACES-621
>          URL: http://issues.apache.org/jira/browse/MYFACES-621
>      Project: MyFaces
>         Type: Bug
>   Components: Tomahawk
>     Versions: Nightly Build
>  Environment: Windows XP, IE
>     Reporter: Ryan Wynn
>     Priority: Minor

>
> Tree2 node commandLinks are not firing their associated method bindings until 
> the commandLink is clicked the second time.  This only happens when the node 
> is shown for the first time after being expanded.
> For example, given tree
> A
>   |_ B
> When tree is in collapsed state, simply A and then expanded as shown above, 
> the first click to B does not invoke associated method binding for B.  A 
> subsequent click to B will work properly.
>  
> This is happening subsequent to MYFACES-580, which fixed the bug where 
> duplicate ids where being complained about.
> Not sure if the 2 are related.
> This is ocurring in 9/24 nightly build.

-- 
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