Tree component puzzle -

Question

Hello
The example i am going to give is one of the issue that make me always wonder if ADF is the right framework for development. I might be of course wrong, it can only prove that we are not on the right track or there a lack of information either or our part or from the part of the Framework developers. We are using Jdeveloper 11g
We have a simple requirement:
Tree is to show the dept employees
Tree node is to show the Emp employee (of course the emps corresponding to the master dept)
This works nicely by following the standard tree implantation.
Then it is required to show only employees who satisfy a certain condition (ie sal > 2000)
We of course modified the EMP viewobject and added a viewCriteria . A been which is invoked by a button action executes the viewCriteria properly
This is the puzzling results
When you expand the tree node, all corresponding employees appear as if the where clause was not executed.
We used the same Emp View object and added a normal table component side by side with the tree, the table shows filtered information as expected
Findings
1) We monitored the executed statement through V$SQL_AREA and found that the action is actually executed.
2)We also found the another statement being executed which matches the dept employees with the emp employees but without the where condition (ie two statements are executed)
One statement select * from emp where deptno = :deptn_no and SaL > :sal
another state select * from emp where deptno = :deptno_no
3) After more debugging, the first statement is executed upon button invocation and actually successfully filters the data, but the user cannot see the filtered data because the tree node is still in collapsed state
4) when the user expands the tree to view the results, the other statement is executed , thus , overwriting the filtered data. and the user (also the developers) stays under the impression that the filtering was not done at all
I don't see how the ADF architects think about it and how come they re-execute the VOlink this way.
I will post it on OTN, but i am back to my original point, Should not this behavior be at least documented, and isnt this scenario a common want to warrant a more straight forward approach
your thoughts
Ammar Sajdi

Answer 1

hello
moh, we already know the reason , but it does not make sense that the framework takes over the behaves the way it wants.
if you invoke the button, the viewCiriteria is executed, and the VO get filtered, and we verified the result be iterating through the ViewObject programmatically after the viewCriteria is executed.
we tried the same with bind variable query, and faced other problems because when you expand the tree, NULL is assumed for the bind variable.
However, when you try to expand the tree node (to verify if the VieWCriteria is executed or not). the Framework issues another query based on the association only (leaving the view criteria). the ADF has no right to mess up the filtered data. Additionally, i do not know why it is re=executing the query every time you open the node, this is not good for performance.
Anyway, we solved in a bad way, through debugging, we noticed that the framework creates an additional VO programmatically (which i think represents the query of the association). We forced filteration on this VO programmatically, and it worked fine! But this is not a good workaround, because if later ADF changes this approach , the code would not work upon upgrade.
The .NET team finished the assignment and did not face such obscure behavior. I think we should drop ADF altogether, it keeps surprising me and advice new adopters to be careful because they will be wasting lots of time guessing how things are done.
and why should groovey need to work?
ammar