1 2 Previous Next 18 Replies Latest reply: Apr 19, 2013 1:57 PM by Don Kleppinger RSS

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

    Jan Vervecken
      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
        • 1. Re: af:table filter date format : task-flow navigation issue
          Frank Nimphius-Oracle
          Jan,

          Appreciate all your findings, and I keep bookmarking them for later follow ups. However, be aware that if you want us to reproduce and file bugs on your behalf, chances are that you are still be sitting on these issues in a next release. Given your excellent analysis and description of the problems, I think most of them could be filed directly as service requests with support so you have them logged and traceable. In the case of the problem reported in this post

          if (q1 == true){
          q2 = "sounds like a bug"
          q3 = "hard to say without a developer debugging what going on"
          }

          Frank
          Ps.: As said, I am keeping track of your posts. However, I have no idea when I am able to follow up
          • 2. Re: af:table filter date format : task-flow navigation issue
            Jan Vervecken
            Thanks for your reply Frank.

            For my questions (q1), (q2) and (q3) in this forum thread, I have also created service request 3-2190488381 on My Oracle Support.

            So, when relevant I do start the "slow" Oracle support process, but some of the reasons to post to this forum are ...
            ... lots of smart people read this forum, and they just might be able to answer my question (or hint to a solution)
            ... it is faster than the Oracle support process
            ... others (or myself, some time in the future) could be searching for information on a related problem (and would be less likely find that information if it only existed in an Oracle bug or service request)
            ... see also http://groups.google.com/group/adf-methodology/msg/8c2ea5fb7a3e0a0b
            ...

            regards
            Jan
            • 3. Re: af:table filter date format : task-flow navigation issue
              Jan Vervecken
              fyi

              Initial feedback in service request 3-2190488381 about (q1).

              The HR schema I used to build the example application had some modifications in the context of https://tuhra2.samplecode.oracle.com/ .
              So after running "demo/schema/mksample" as documented in "Resetting Sample Schemas" ...
              at http://download.oracle.com/docs/cd/E11882_01/server.112/e10831/installation.htm#I6236
              ... I got "java.sql.SQLSyntaxErrorException: ORA-00904: "EMPLOYEES"."MODIFIED_DATE": invalid identifier ", using the example application in TableFilterDateFormatIssueApp-v0.03.zip.

              So, I have updated the example application to match the reset HR schema,
              see http://www.consideringred.com/files/oracle/2010/TableFilterDateFormatIssueApp-v0.04.zip
              Using that, I am still able to reproduce scenario (sc1), so questions (q1), (q2) and (q3) remain.

              regards
              Jan
              • 4. Re: af:table filter date format : task-flow navigation issue
                Jan Vervecken
                fyi

                In the context of service request 3-2190488381
                - about (q1), yes, the behaviour in scenario (sc1) can be reproduced
                - bug 10193260, "AF:TABLE FILTER DATE FORMAT : TASK-FLOW NAVIGATION ISSUE", has been logged

                regards
                Jan
                • 5. Re: af:table filter date format : task-flow navigation issue
                  Frank Nimphius-Oracle
                  Thanks Jan.

                  As said, appreciate the depth of analysis of the problems you face. I just need to be sure I am not getting on a case that customer support already has an action filed for. This is why I need to be sure bugs are filed or at least be aware that none is filed.

                  Frank

                  Ps.: Thanks for also documenting the issues for people searching the forums for similar cases
                  • 6. Re: af:table filter date format : task-flow navigation issue
                    Jan Vervecken
                    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
                    • 7. Re: af:table filter date format : task-flow navigation issue
                      Jan Vervecken
                      hi

                      Still trying to understand which part of the suggested workaround (clearing the search fields during taskflow exit) are essential and for which parts implementation improvements are desirable.
                      For example in the forum thread "calling ApplicationModule.findViewObject() in a managed-bean"
                      at calling ApplicationModule.findViewObject() in a managed-bean

                      One could also argue that the suggested workaround also implies a functional change as the table is no longer filtered when arriving on the page again after it was filtered before, where the table was still filtered when the workaround was not applied.

                      Using the implementation of the workaround in TableFilterDateFormatIssueApp-v0.05.zip reveals a scenario (sc2) that still results in the error "The date is not in the correct format." even if the suggested workaround is implemented,
                      as shown in the screencast at http://screencast.com/t/wUdZBXDaw
                      It involves a potentially "unrelated task-flow" using the same View Object instance together with the task-flow that does implement the workaround (clearing the search fields during taskflow exit).

                      - (q6) Does an alternative or improved workaround exist to avoid the error "The date is not in the correct format." like in scenario (sc2)?

                      regards
                      Jan
                      • 8. Re: af:table filter date format : task-flow navigation issue
                        Jan Vervecken
                        repost

                        Questions (q5) and (q6) remain.

                        regards
                        Jan
                        • 9. Re: af:table filter date format : task-flow navigation issue
                          Frank Nimphius-Oracle
                          Jan,

                          I changed the date filter component convertDateTime pattern, setting the secondaryPattern

                          <af:inputDate value="#{vs.filterCriteria.HireDate}" id="id1">
                          <f:validator binding="#{bindings.HireDate.validator}"/>
                          <af:convertDateTime pattern="#{bindings.HireDate.format}"
                          secondaryPattern="yyyy-MM-dd"/>
                          </af:inputDate>

                          and the problem doesn't show even in your original sample. I think from all the questions you asked about least impact, setting a secondary pattern - if it works for you and despite the fact that the date format changes - looks perfect.

                          However, this now bears the question of what users would expect when re-entering a bounded task-flow

                          i) have the table filtered as you left it
                          ii) have the date field cleared

                          So possibly the workaround still makes sense for the second use case

                          Frank
                          • 10. Re: af:table filter date format : task-flow navigation issue
                            Jan Vervecken
                            Thanks for your reply Frank.

                            Your suggestion to configure secondaryPattern="yyyy-MM-dd" seems to avoid the "The date is not in the correct format." error message for a scenario similar to (sc1).
                            I have modified the example application to include this suggestion
                            at http://www.consideringred.com/files/oracle/2011/TableFilterDateFormatIssueApp-v0.06.zip
                            as can be seen in scenario (sc3) in the screencast at http://screencast.com/t/qogJ2775I

                            The secondaryPattern for af:convertDateTime is documented as
                            "Second pattern, which will be used as a second attempt to parse a string if the primary pattern or styles fail, but is never used for formatting strings.".
                            ... I think from all the questions you asked about least impact, setting a secondary pattern - if it works for you and despite the fact that the date format changes - looks perfect.
                            Well, it avoids the error message, but not the confusion for end-users resulting from the use of different date formats.
                            - (q7) How is not being able to consistently use one single date format in all aspects of the application, not a bug?
                            However, this now bears the question of what users would expect when re-entering a bounded task-flow

                            i) have the table filtered as you left it
                            ii) have the date field cleared
                            Do you consider choosing between i) and ii) a choise that the framework should make?
                            Shouldn't this be something the application developer can choose so that functional requirements can be met?
                            Whatever the behaviour, isn't it fair to expect at least consistency so that the filter value matches the data shown?
                            So possibly the workaround still makes sense for the second use case
                            I don't understand what you suggest here. Which "the workaround" are you referring to?

                            thanks
                            Jan
                            • 11. Re: af:table filter date format : task-flow navigation issue
                              Jan Vervecken
                              fyi

                              I have posted some related questions in forum thread "task-flow table filtering behaviour related to bug 8602867"
                              at task-flow table filtering behaviour related to bug 8602867

                              But, in this forum thread (q7) and aspects of (q5) and (q6) remain.

                              regards
                              Jan
                              • 12. Re: af:table filter date format : task-flow navigation issue
                                Jan Vervecken
                                fyi

                                Yesterday I got this feedback in service request 3-2190488381 :
                                Kindly here is the development team feedback:
                                They do confirm that QBE was never designed to work with Query and they can not make changes at this time so you should use the workaround.
                                Also This issue is not a bug as it has never been a requirement but they are considering it into their plans to design QBE to work with Query in the next releases.
                                I do not understand what "QBE was never designed to work with Query " means in this context.
                                About "... so you should use the workaround ...", which workaround is that? For the "clearFilterFields() workaround " suggested by development questions (q5) and (q6) remain, and for the "secondaryPattern workaround " suggeted by Frank Nimphius question (q7) remains.
                                I also noticed that bug 10193260 has "Status 32 - Not a Bug. To Filer " again.

                                So, I do not really see how this feedback answers my questions:
                                - (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?
                                - (q6) Does an alternative or improved workaround exist to avoid the error "The date is not in the correct format." like in scenario (sc2)?
                                - (q7) How is not being able to consistently use one single date format in all aspects of the application, not a bug?

                                regards
                                Jan
                                • 13. Re: af:table filter date format : task-flow navigation issue
                                  Jan Vervecken
                                  fyi

                                  Recent feedback in SR 3-2190488381 :
                                  Kindly here is the developer's feedback:

                                  The core of this issue is that when the user types values in the table filter fields we convert the value into a String and pass it on to Adfm for a SQL query via VC/VCItems. When the user comes back into a task flow the VC/VItems are parsed back into the filter fields. The parsing back in logic is not as strong as the one where we convert the user values into a complex VC, with nested and/or operator. For e.g. if a user does filtering with and(s)/or(s) inside filter fields, exits and then re-enters the task flow the complex sql is lost. Instead the parsing logic can only handle 1 row of VC. This is an existing design flaw in our system. The initial implementation was not properly designed to handle the exit/reenter task flow scenarios. We have an ER to address this for a future release.

                                  Another manifestation of this design flaw is that the Date values that are converted into a string version of SQL date is not parsed back in correctly because the convertDateTime pattern is not specified to handle this. Like Frank mentioned in the forum specifying the secondaryPattern fixes this issue. The example filter inputDate field needs to be specified as follows:

                                  <af:inputDate value="#{vs.filterCriteria.HireDate}" id="id1">
                                  <f:validator binding="#{bindings.HireDate.validator}"/>
                                  <af:convertDateTime pattern="#{bindings.HireDate.format}"
                                  secondaryPattern="yyyy-MM-dd"/>
                                  </af:inputDate>

                                  Alternatively we could do this conversion internally when the VC/VCItems are parsed into filter fields. However this would be a change in behavior in our code. We are not allowed to change behavior in an existing app releases since someone could be taking advantage of the old behavior.

                                  Also note that since the parsing logic was weak(for complex queries) we were suggesting that the filter fields be completely cleared on exit. That way when a user re-enters the taskflow he/she can re-query.

                                  To answer your questions, here are the choices:

                                  1. Customer changes all the filter date fields to have the secondaryPattern to avoid the parsing error with dates. This would make the app work in most cases except when the use types complex filter values with and/or etc.

                                  2. Customer changes the apps so that the filter fields are cleared on a task flow exit. They may have to do this only in case of ones that can be re-entered with the same VC. They might also do with where the filterable table shares a VC from one task flow to another.

                                  3. We implement an ER to handle the loading of the VCItem values into the filter fields to handle the dates in the correct format and also let it handle complex nested VCs (and/or filter case).

                                  I doubt 3. will be approved by the management at this point for a back release. So I would either choose 1 or 2. Because 2 would be most consistent behavior form the user's view point I was suggesting this option. In a future release when we implement 3, customer has to go back and remove the logic to clear the filter fields.
                                  One way to read this is, there is a "design flaw" for which an enhancement request (not a bug) exists and no product changes (fixes) are possible for the current production release.

                                  So, I will have to take another look at the "clearFilterFields() workaround" ("2." above), but as I wrote before in this forum thread "It looks like a more general/generic approach is desirable for the suggested workaround to be feasible. ".

                                  regards
                                  Jan
                                  • 14. Re: af:table filter date format : task-flow navigation issue
                                    Jan Vervecken
                                    hi

                                    - Opening and running TableFilterDateFormatIssueApp-v0.06.zip using JDeveloper 11.1.1.4.0 only results in minor changes by JDeveloper
                                    at http://www.consideringred.com/files/oracle/2011/TableFilterDateFormatIssueApp-v0.07.zip
                                    ... for which the behaviour for the different scenario's remains the same.

                                    - feedback in SR 3-2190488381 says about "choice 1. "
                                    ... This would make the app work in most cases except when the use types complex filter values with and/or etc.
                                    The af:inputDate component in the filter facet does not seem to accept "complex filter values",
                                    as shown in scenario (sc4) the screencast at http://screencast.com/t/VzeAW00bUF

                                    (q8) Which specific scenario for the "secondaryPattern workaround ", e.i. "choice 1. ", involving "complex filter values", would make the application fail as suggested?

                                    thanks
                                    Jan
                                    1 2 Previous Next