Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 2.0.0
-
Fix Version/s: 2.0.1
-
Component/s: ICE-Components
-
Labels:None
-
Environment:ICEfaces 2
-
Assignee Priority:P1
-
Workaround Exists:Yes
-
Workaround Description:
Description
http://www.icefaces.org/JForum/posts/list/17692.page
http://www.icefaces.org/JForum/posts/list/18306.page
http://jira.icefaces.org/browse/ICE-3983?focusedCommentId=29886&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_29886
From the forums threads, and JIRA comment, it appears that several code paths in Tree and TreeNode are running, when Tree.rendered=false or TreeNode.rendered=false, leading to garbled display, and invalid application state.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Salesforce Case | [] | |
| Fix Version/s | 2.0.1 [ 10255 ] |
| Salesforce Case | [] | |
| Assignee Priority | P2 | |
| Assignee | Arturo Zambrano [ artzambrano ] |
| Assignee | Arturo Zambrano [ artzambrano ] | Mark Collette [ mark.collette ] |
| Salesforce Case | [] | |
| Assignee Priority | P2 | P1 |
In the first image, the lines are terminated properly, in the second image, the lines continue on improperly.
| Attachment | Screen shot 2011-01-25 at 2.28.22 PM.png [ 12821 ] | |
| Attachment | Screen shot 2011-01-25 at 2.28.40 PM.png [ 12822 ] |
With ice:treeNode having rendered=false, the issue is that when a tree node is rendered, and it is rendering it's lines, it needs to know if it had a preceding sibling and if it has a subsequent sibling. It uses APIs in DefaultMutableTreeNode to determine this. But, when the initial preceding or final subsequent nodes do exist, but have rendered=false, that confuses the rendering process, since the current node can't know that other nodes are unrendered, since the EL for the other nodes wouldn't evaluate, as the EL is wired to the current node. DefaultMutableTreeNode does not have any APIs covering the concept of a node existing but not being shown. So what we have is a conflict between that limited API, and the JSF notion of lazily evaluating rendered, to determine that a node should not be processed.
Three solutions come to mind:
1. Application work-around, where the tree model passed to the tree has had any unrendered nodes pruned. So there might be a master data model with all nodes, and a copy of that which is pruned for the current display. Once the pruning has taken place, this should actually render the tree the fastest.
2. Add an API to the IceUserObject, which will cover whether a node is to rendered. The tree code may check the model, as it's rendering, with no reliance on EL, so it should be reasonably fast. There's a slight backwards incompatibility in adding to IceUserObject, as existing applications might already make use of methods with the same names.
3. The slowest solution would be when rendering a node, to switch the EL resolution to forward inspect the subsequent nodes, and then bounce back to the current node.
| Workaround Description |
If the data model includes nodes that should not currently be rendered, then instead of using that master data model, build a cloned and pruned data model, and have the tree use that. |
|
| Workaround Exists | [Yes] | |
| Salesforce Case | [] |
Won't fix the unrendered node issue, since an application work-around exists.
| Status | Open [ 1 ] | Closed [ 6 ] |
| Resolution | Won't Fix [ 2 ] |
I can reproduce the issue with ice:treeNode having rendered=false, and the navigation lines showing. Refer to
ICE-3983and it's second attached image.