I am using Primefaces 3.4.1 with a milestone of build 2.2.0-m05 implementing Oracle JSF 2.2. I also use Spring 3.1 for dependency injection and some AOP.
I am trying to use the Performance tree component to display the composite logic filter rules (and allows the user to create composite / sheet nodes at any depth in the composite structure).
Compound filter example:
((location = 'cal') AND (description contains 'test')) OR (project = 'someProject')
Example tree layout:
<p:tree value="#{form.rootComponent}" var="filterComponent" animate="true"> <p:treeNode type="composite"> </p:treeNode> <p:treeNode type="leaf"> </p:treeNode> </p:tree>
Although the element's value attribute accepts the root TreeNode (derived from a managed bean), the var attribute points to the actual data present in the current node tree, not the node itself. I would like to access the current node tree, not its wrapped data, either tagged or programmatically .
If I can access it in markup, I can pass it as a method argument to a managed bean. If there is no way to access it in the markup, can I get direct programmatic access through the model object? (presumably by accessing the underlying tree model?).
I know that you can use an expression that resolves the underlying DataModel instead of collecting data directly as the "value" of h: dataTable, but I believe that you can only use the root of the node with p: tree.
I could include a reference to the node tree in the wrapped data object, but I would rather avoid the nasty circular references, if at all possible.
In the absence of a better alternative, I tried to use the binding attribute to bind the p: tree element directly to the tree instance in a managed bean (Tree is the UIComponent class for p: tree), which allows me to access the current node using the getTreeNode () method, but I would prefer to avoid this, given the life cycle mismatch between managed beans and view components. It does not work as it is, and I assume that there should be a much better and simpler solution.
I also tried using the jsf data table - with nested data tables to process the component, but decided against it, given the complexity of creating a conditionally recursive structure in jsf markup (I believe the "rendered" attribute is not evaluated in view build time so that it hard to avoid endless recursion).
Just to clarify, I'm only interested in the current node tree containing the data referenced by "var", not the node selected by the user.