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

        Hide
        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
        Hide
        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.
        Hide
        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
        Hide
        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.
        Hide
        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.
        Hide
        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 .

          People

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

            Dates

            • Created:
              Updated:
              Resolved: