ICEfaces
  1. ICEfaces
  2. ICE-7962

Paginator can't use expression for attributes

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-3.0.0.GA
          • Fix Version/s: 3.1.0.BETA1, 3.1
          • Component/s: Sample Apps
          • Labels:
            None
          • Environment:
            Showcase App Mojarra MyFaces
          • Assignee Priority:
            P2
          • Affects:
            Sample App./Tutorial

            Description

            While the issue can be replicated with our showcase example, it's not specific to ICEfaces and can be reproduced in a simple test case running either Mojarra or MyFaces

            To reproduce:
            - build showcase with Myfaces (ant clean servlet profile -Dmyfaces="true") or Mojarra
            - deploy to Tomcat7.
            - load the page in any browser: http://localhost:8080/showcase/showcase.jsf?exp=dataTableBean&grp=aceMenu
            - choose the Pagination example
            - select on the page: Table Rows (1-30) = 5 and tab out
            - then change Selected Page (1-6) = 6 and submit.
            - a validation message renders on the page: "Specified attribute is not between the expected values of 1 and 3."

            The issue being that use of an EL expression for the maximum attribute doesn't work.

              Activity

              Ascending order - Click to sort in descending order
              Carmen Cristurean created issue -
              Hide
              Permalink
              Carmen Cristurean added a comment -

              Nils said:

              private int rows = 10;
              ... public int getStartPageMaximum()

              { return (int)Math.ceil(30.0/(double)rows); }

              so there should only be 3 pages by default. changing to 5 rows should cause statePageMaximum to return 6
              and it does because the text says pages 1-6
              however the validator isn't updated somehow
              nothing to do with the table directly
              looks like it could be myfaces issue with validators

              Show
              Carmen Cristurean added a comment - Nils said: private int rows = 10; ... public int getStartPageMaximum() { return (int)Math.ceil(30.0/(double)rows); } so there should only be 3 pages by default. changing to 5 rows should cause statePageMaximum to return 6 and it does because the text says pages 1-6 however the validator isn't updated somehow nothing to do with the table directly looks like it could be myfaces issue with validators
              Evgheni Sadovoi made changes -
              Field Original Value New Value
              Assignee Evgheni Sadovoi [ evgheni.sadovoi ]
              Ken Fyten made changes -
              Salesforce Case []
              Fix Version/s 3.1 [ 10312 ]
              Assignee Priority P2
              Assignee Evgheni Sadovoi [ evgheni.sadovoi ] Deryk Sinotte [ deryk.sinotte ]
              Hide
              Permalink
              Deryk Sinotte added a comment -

              MyFaces saves and restores state on every request. In this case, it's restoring the state of the validator to the values it had when it was saved. In this case, it was saved when the bean value was 1-3 and wasn't updated to 1-6 (presumably because the validator is resolved before the rows+pages values can be resolved and recalculated) so the validation fails. In short, the validation min/max values are always one state behind when they validation is applied.

              However, I'm finding that Mojarra is doing the same thing. You can see it on the public version of the showcase:

              http://icefaces-showcase.icesoft.org/

              So it appears it's not specific to the RI. Instead we need a different way to do the dynamic maximum value in the validator. Assigning back to Ken for changing how we do the validation. I'll log bug/test case into MyFaces and Mojarra.

              Show
              Deryk Sinotte added a comment - MyFaces saves and restores state on every request. In this case, it's restoring the state of the validator to the values it had when it was saved. In this case, it was saved when the bean value was 1-3 and wasn't updated to 1-6 (presumably because the validator is resolved before the rows+pages values can be resolved and recalculated) so the validation fails. In short, the validation min/max values are always one state behind when they validation is applied. However, I'm finding that Mojarra is doing the same thing. You can see it on the public version of the showcase: http://icefaces-showcase.icesoft.org/ So it appears it's not specific to the RI. Instead we need a different way to do the dynamic maximum value in the validator. Assigning back to Ken for changing how we do the validation. I'll log bug/test case into MyFaces and Mojarra.
              Deryk Sinotte made changes -
              Salesforce Case []
              Affects [Sample App./Tutorial]
              Assignee Deryk Sinotte [ deryk.sinotte ] Ken Fyten [ ken.fyten ]
              Ken Fyten made changes -
              Salesforce Case []
              Fix Version/s 3.1.0.BETA1 [ 10335 ]
              Deryk Sinotte made changes -
              Summary showcase - ace:dataTable - Paginator - incorrect validation on the page when using MyFaces JSF showcase - ace:dataTable - Paginator - incorrect validation on the page
              Salesforce Case []
              Fix Version/s 3.1.0.BETA1 [ 10335 ]
              Assignee Ken Fyten [ ken.fyten ] Deryk Sinotte [ deryk.sinotte ]
              Deryk Sinotte made changes -
              Environment EE-3.0.GA build 10 (showcase app built with myFaces)
              Server: Tomcat7
              Browsers: All               		Showcase App
              Salesforce Case []
              Hide
              Permalink
              Deryk Sinotte added a comment -

              I've opened up cases in both Mojarra and MyFaces systems for this behaviour:

              http://java.net/jira/browse/JAVASERVERFACES-2417
              https://issues.apache.org/jira/browse/MYFACES-3547

              Show
              Deryk Sinotte added a comment - I've opened up cases in both Mojarra and MyFaces systems for this behaviour: http://java.net/jira/browse/JAVASERVERFACES-2417 https://issues.apache.org/jira/browse/MYFACES-3547
              Deryk Sinotte made changes -
              Summary showcase - ace:dataTable - Paginator - incorrect validation on the page Paginator can't use expression for attributes
              Environment Showcase App Showcase App Mojarra MyFaces
              Salesforce Case []
              Description In the showcase application built with myFaces, on the ace:dataTable -> Paginator page:
               selecting Table Rows (1-30) = 5 and Selected Page (1-6) = 6 , a validation message renders on the page: "Specified attribute is not between the expected values of 1 and 3."

              This does not appear to be correct. This is not an issue when using Mojarra JSF.

              To reproduce:
              - build showcase with Myfaces (ant clean servlet profile -Dmyfaces="true"), deploy to Tomcat7.
              - load the page in any browser: http://localhost:8080/showcase/showcase.jsf?exp=dataTableBean&grp=aceMenu
              - select on the page: Table Rows (1-30) = 5 and Selected Page (1-6) = 6 and submit.               		While the issue can be replicated with our showcase example, it's not specific to ICEfaces and can be reproduced in a simple test case running either Mojarra or MyFaces

              To reproduce:
              - build showcase with Myfaces (ant clean servlet profile -Dmyfaces="true") or Mojarra
              - deploy to Tomcat7.
              - load the page in any browser: http://localhost:8080/showcase/showcase.jsf?exp=dataTableBean&grp=aceMenu
              - choose the Pagination example
              - select on the page: Table Rows (1-30) = 5 and tab out
              - then change Selected Page (1-6) = 6 and submit.
              - a validation message renders on the page: "Specified attribute is not between the expected values of 1 and 3."

              The issue being that use of an EL expression for the maximum attribute doesn't work.
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #29060 Wed May 16 09:40:23 MDT 2012 deryk.sinotte ICE-7962
              Files Changed
              Commit graph MODIFY /icefaces3/trunk/icefaces/samples/showcase/showcase/src/main/webapp/resources/examples/ace/dataTable/dataTablePaginator.xhtml
              Commit graph MODIFY /icefaces3/trunk/icefaces/samples/showcase/showcase/src/main/java/org/icefaces/samples/showcase/example/ace/dataTable/DataTablePaginator.java
              Hide
              Permalink
              Deryk Sinotte added a comment -

              For now, I've modified the example by removing the validator and simply using logic in the backing bean to ensure that the pages value stays within the min/max limits.

              Show
              Deryk Sinotte added a comment - For now, I've modified the example by removing the validator and simply using logic in the backing bean to ensure that the pages value stays within the min/max limits.
              Deryk Sinotte made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Hide
              Permalink
              Deryk Sinotte added a comment -

              According to feedback on the MyFaces ticket from Leonardo Uribe:

              "It is a known weakness in jsf standard converters and validator. To overcome this limitation, some converters and validators were created in MyFaces Commons project that evaluates its parameters when the value is checked, There is no variant for f:validateLongRange, but there is a mcc:convertNumber and mcc:convertDateTime.

              Unfortunately, by compatibility with the spec it is not possible to change the current behavior. A change should be done at spec level. It is possible to write a custom implementation of that validator using myfaces builder plugin."

              So right now the answer is that you can't do this until the spec changes and the solution is to do it in a custom fashion (or use the custom ones supplied by MyFaces). No comment from the Mojarra group yet.

              Show
              Deryk Sinotte added a comment - According to feedback on the MyFaces ticket from Leonardo Uribe: "It is a known weakness in jsf standard converters and validator. To overcome this limitation, some converters and validators were created in MyFaces Commons project that evaluates its parameters when the value is checked, There is no variant for f:validateLongRange, but there is a mcc:convertNumber and mcc:convertDateTime. Unfortunately, by compatibility with the spec it is not possible to change the current behavior. A change should be done at spec level. It is possible to write a custom implementation of that validator using myfaces builder plugin." So right now the answer is that you can't do this until the spec changes and the solution is to do it in a custom fashion (or use the custom ones supplied by MyFaces). No comment from the Mojarra group yet.
              Ken Fyten made changes -
              Salesforce Case []
              Fix Version/s 3.1.0.BETA1 [ 10335 ]
              Security Private [ 10001 ]
              Hide
              Permalink
              Deryk Sinotte added a comment -

              This has been changed to a spec issue: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1104.

              Show
              Deryk Sinotte added a comment - This has been changed to a spec issue: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1104 .
              Deryk Sinotte made changes -
              Link This issue is duplicated by ICE-8049 [ ICE-8049 ]
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]

                People

                • Assignee:
                  Deryk Sinotte
                  Reporter:
                  Carmen Cristurean
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: