Af:table filter date format : task-flow navigation issue

Question

hi
When trying to use the date format configured on the Entity Object, with Format Type as Simple Date and Format as "dd-MM-yyyy", there seems to be a problem when using task-flows.
The approach involves an explicitly configured attributeValues binding to use in f:validator and af:convertDateTime components in the af:inputDate in the filter facet, as discussed in the forum thread "af:table filter date format"
at af:table filter date format
I used JDeveloper 11.1.1.3.0 to create the example application
in http://www.consideringred.com/files/oracle/2010/TableFilterDateFormatIssueApp-v0.03.zip
- The page filterEmp.jspx shows expected behaviour, the filter uses the configured date format and there is no problem when navigating to another page and back.
see the screencast at http://screencast.com/t/CtQ9rsVFH3k
- The page menuBTFPage.jspx allows for some navigation after using the filter resulting in the filter showing a date in the wrong format, using scenario (sc1)
-- (sc1-a) : run menuBTFPage.jspx
-- (sc1-b) : on "menu-btf : menu", click the "do go-filter-emp-btf" link
-- (sc1-c) : on "filter-emp-btf : filterEmpFragment", filter on HireDate using "10-03-2005"
-- (sc1-d) : click the "do goReturnSuccess" button
-- (sc1-e) : back on "menu-btf : menu", click the "do go-filter-emp-btf" link again
-- (sc1-f) : back on "filter-emp-btf : filterEmpFragment", see the HireDate filter value in the wrong format as "2005-03-10"
-- (sc1-g) : click the "do goReturnSuccess" button again, which results in an error "The date is not in the correct format."
see the screencast at http://www.screencast.com/t/ORHauBd3oQ
questions:
- (q1) Can the behaviour in scenario (sc1) be reproduced?
- (q2) Why is the filter value in the wrong date format in step (sc1-f)?
- (q3) What can be done to have the filter value consistently in the configured date format, so that errors as in step (sc1-g) can be avoided?
many thanks
Jan Vervecken

Answer 1

hi
First a short summary of relevant aspects of service request 3-2190488381:
- development has reviewed bug 10193260
- development identified some code where a pattern was not applied and started fixing the problem
- out of the blue, development asked "Will clearing out the filter field completely when moving out of ataskflow be an acceptable behavior ?"
- I pointed out some concerns (even in a phone call with development), but development did not see any alternative not "perceived to be very risky because of the current design", so the question whether the clearing-all-filter-fields approach would be acceptable became superfluous.
- following this, bug 10193260 suddenly became an enhancement request (for reasons I still don't understand)
- a workaround was suggested (for behaviour not perceived as a bug), "Clearing the search fields during taskflow exit in the backing bean (in the app)." for which I also received a modified version of my example application TableFilterDateFormatIssueApp-v0.04.zip with an implementation of the suggested workaround
As an exercise to try an understand the suggested workaround (an because my example application seemed to have been modified using the currently yet-to-be-released JDeveloper 11.1.1.4.0) I re-implemented it in the example application
at http://www.consideringred.com/files/oracle/2010/TableFilterDateFormatIssueApp-v0.05.zip
It has a filter-emp-workaround-btf task-flow with a method-call activity on a managed-bean method, responsible for clearing the search fields, resulting in behaviour where the error "The date is not in the correct format." does not occur,
as can be seen in the screencast at http://screencast.com/t/Nq7TkkRQ
  public void clearFilterFields()
    BindingContainer vBindingContainer =
      BindingContext.getCurrent().getCurrentBindingsEntry();
    DCBindingContainer vDCBindingContainer = (DCBindingContainer)vBindingContainer;
    DCDataControl vDCDataControl = vDCBindingContainer.getDataControl();
    ApplicationModule vApplicationModule = vDCDataControl.getApplicationModule();
    ViewObject vViewObject = vApplicationModule.findViewObject("EmployeesVOVI");
    ViewCriteriaManager vViewCriteriaManager = vViewObject.getViewCriteriaManager();
    vViewCriteriaManager.clearViewCriterias();
    vViewObject.clearCache();
  }Because the managed-bean method requires access to the ADF Model binding layer to get to the View Object instance used for the filtered table, the method-call activity has a page element configured in DataBindings.cpx referring to the same usageId as the page element for the page fragment showing the filtered table. So that both the method-call and view activity depend on one and the same Binding Container (e.i. PageDef file).
The method-call activity, responsible for clearing the search fields, would need to be called before each task-flow-return activity.
As there can be multiple view activities with multiple filtered tables in a bounded task-flow, would that result in multiple method-call activities responsible for clearing search fields (all to be called before each task-flow-return activity)?
It looks like a more general/generic approach is desirable for the suggested workaround to be feasible.
- (q5) Does the suggested workaround imply (as bug 10193260 is not a bug) that all bounded task-flows with filtered tables should implement it to avoid errors about formatting?
thanks
Jan