ADF : af:query saved search issue

Question

hi
Please consider this example application from Andrejus Baranovskis
http://jdevsamples.googlecode.com/files/UserCustomizationsSession.zip
(which he refers to from his blog post "User Customizations for Duration of Session in Oracle ADF 11g")
I see some strange behaviour with a saved search in this scenario:
(a1) open the UserCustomizationsSession.jws file in JDeveloper 11.1.1.1.0 and configure the "Hr" database connection in the Application Resources panel
(a2) right-click the main.jspx page in the ViewController project and click Run
(a3) on the "Index" page click the "Employees" button
(a4) on the "Employees Form" page, without entering any search values, click the "Search" button, which causes (all) the rows to show in the table
(a5) in the "Firstname" search field, enter "a" and click the "Search" button, which causes rows with "a" in their first name to show in the table
(a6) click the "Save..." button
(a7) in the "Create Saved Search" dialog, enter "my-a-search" in the "Name" field and keep the default values for the checkboxes ("Set as Default" checked, "Run Automatically" checked and "Save Results Layout" unchecked) and click "OK", which causes "my-a-search" to show up in the "Saved Search" dropbox
(a8) click the "Close" button
(a9) on the "Index" page click the "Employees" button, which causes the "Employees Form" page to show up with the results of "my-a-search"
(a10) in the "Saved Search" dropbox, select "EmployeesViewCriteria" and click the "Search" button, which seems to cause the table to refresh but still showing what seems to be the result of "my-a-search"
(a11) try to change the value of the "FirstName" search field or use the "Reset" button, each time the result of "my-a-search" shows up
question
(q1) Why don't I get all the rows in step (a10) instead of just "my-a-search"?
many thanks
Jan Vervecken

Answer 1

Hi Jan,
seems related to bug 8817108 - AF:QUERY DOES NOT WORK CORRECTLY WITH MUTIPLE VIEW CRITERIA
I'm copying below an except of the SR with possible workarounds:
The key point in the modified testcase is that we created a method in the
Application Module that resets the View Criteria of the View Object:
    public void unapplyViewCriteria() {
        String[] allVC = getViewObj1().getAllViewCriteriaNames();
        for (String vc: allVC )  {
            System.out.println("Unapply View Criteria: " + vc);
            getViewObj1().removeApplyViewCriteriaName(vc);
    }This method was published as a client interface and added to the bindings of
the Page definition (by a drag&drop from the DataControl palette):
    <methodAction id="unapplyViewCriteria" RequiresUpdateModel="true"
                  Action="invokeMethod" MethodName="unapplyViewCriteria"
                  IsViewObjectMethod="false" DataControl="AppModuleDataControl"
                  InstanceName="AppModuleDataControl.dataProvider"/>This created a button that we updated as the following:
        <af:commandButton
                          text="Go To Other Page AND Unapply View Criteria"
                          disabled="#{!bindings.unapplyViewCriteria.enabled}"
                          id="cb1"
                          actionListener="#{bindings.unapplyViewCriteria.execute}"
                          action="otherpage"/>This button will execute unapplyViewCriteria() and then navigate to the other page.
That's a first solution, where we unset the View Criteria just when navigating.
Another option is to unapply the ViewCriteria when the af:query has completed its query.
This can be done by the method we exposed in the aforementioned Note.
The method processQuery() in the backing bean is:
    public void processQuery(QueryEvent queryEvent) {
         * add your PreQuery code here
         * invoke the real processQuery
        invokeMethodExpression("#{bindings.NameStartsWithMQuery.processQuery}",
                               Object.class, QueryEvent.class, queryEvent);
         * add your PostQuery code here
        // Workaround for Bug 8817108
        BindingContainer bindings = getBindings();
        OperationBinding operationBinding = bindings.getOperationBinding("unapplyViewCriteria");
        Object result = operationBinding.execute();
    }where we first execute the standard processQuery, and then unapply the View Criteria.
If memory serves me well, customer opted for WA 2.
Regards,
Didier.