MyFaces Trinidad
  1. MyFaces Trinidad
  2. TRINIDAD-1195

Length validator broken if "maximum" attributes is missing

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.9-core
    • Fix Version/s: 1.2.10-core, 1.0.10-core
    • Component/s: None
    • Labels:
      None

      Description

      <tr:validateLength minimum="2">

      Client side validation always results in "Enter 2 or more characters, up to a maximum of 0."
      No valid data can be entered at all.

      Server side validation works in principal, but spits out an incorrect message when the validation (correctly) fails: "Enter 0 or more characters, not fewer."

      See https://issues.apache.org/jira/browse/TRINIDAD-1130 for test.war that you can simply drop into Tomcat 6.

      Much of my code omits the "maximum" attribute, because I have a maximum length set on my input components (so that joe user just cannot enter more characters anyway) and have wrapped the form in a seam validation (s:validateAll) that validates on the server side against constraints set with hibernate validation annotations on the entity objects (so that a hacker can do no harm).

      1. 0-or-more-not-fewer.png
        1 kB
        Stephen Friedrich
      2. 2-up-to-a-maximum-of-0.png
        1 kB
        Stephen Friedrich
      3. confused.PNG
        38 kB
        Matthias Weßendorf
      4. server-side1.PNG
        39 kB
        Matthias Weßendorf
      5. server-side2.PNG
        32 kB
        Matthias Weßendorf

        Activity

        Hide
        Matthias Weßendorf added a comment -

        Tested this (in JSPX):
        <tr:inputText>
        <tr:validateLength minimum="2"/>
        </tr:inputText>

        (default setting is that client side is turned on)

        with 1.2.x trunk (1.2.10-SNAPSHOT)
        entered "ABCDEF" ==> FINE (as expected)
        entered "A" => ERROR (as expected)

        I know you are using seam. Is it possible that some JAR (like Trinidad) overrides the id's for the validators?
        Trinidad's tag creates the Validator (and the converter) based on the ID.

        Show
        Matthias Weßendorf added a comment - Tested this (in JSPX): <tr:inputText> <tr:validateLength minimum="2"/> </tr:inputText> (default setting is that client side is turned on) with 1.2.x trunk (1.2.10-SNAPSHOT) entered "ABCDEF" ==> FINE (as expected) entered "A" => ERROR (as expected) I know you are using seam. Is it possible that some JAR (like Trinidad) overrides the id's for the validators? Trinidad's tag creates the Validator (and the converter) based on the ID.
        Hide
        Stephen Friedrich added a comment -

        No, this is not a seam issue.
        See the war file in TRINIDAD-1130 for a complete test application (including deployable war, jsp, sources and even an ant script).
        That test.war is the minimal application using trinidad and mojarra that I could think of.

        Show
        Stephen Friedrich added a comment - No, this is not a seam issue. See the war file in TRINIDAD-1130 for a complete test application (including deployable war, jsp, sources and even an ant script). That test.war is the minimal application using trinidad and mojarra that I could think of.
        Hide
        Matthias Weßendorf added a comment -

        I am sorry to say, that I am still (not used your app) able to get the error with the latest greatest Trinidad 1.2.10-SNAPSHOT.

        Did a check out of this:
        https://svn.apache.org/repos/asf/myfaces/trinidad/trunk_1.2.x/
        did the build => mvn install

        started the trinidad-demo, using JSF RI 1.2_09
        cd trinidad-examples/trinidad-demo
        mvn -PjettyConfig -Djsf=ri jetty:run

        My page is pretty simple:
        <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
        <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
        xmlns:f="http://java.sun.com/jsf/core"
        xmlns:tr="http://myfaces.apache.org/trinidad" >
        <jsp:directive.page contentType="text/html;charset=utf-8"/>
        <f:view>
        <tr:document title="Apache Trinidad Demo Index">
        <tr:form>
        <tr:panelFormLayout>

        <tr:inputText>
        <tr:validateLength minimum="2"/>
        </tr:inputText>

        <tr:commandButton text="Go" />
        </tr:panelFormLayout>
        </tr:form>
        </tr:document>
        </f:view>
        </jsp:root>

        Next step is checking your WAR w/ updated JARs.

        Show
        Matthias Weßendorf added a comment - I am sorry to say, that I am still (not used your app) able to get the error with the latest greatest Trinidad 1.2.10-SNAPSHOT. Did a check out of this: https://svn.apache.org/repos/asf/myfaces/trinidad/trunk_1.2.x/ did the build => mvn install started the trinidad-demo, using JSF RI 1.2_09 cd trinidad-examples/trinidad-demo mvn -PjettyConfig -Djsf=ri jetty:run My page is pretty simple: <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0" xmlns:f="http://java.sun.com/jsf/core" xmlns:tr="http://myfaces.apache.org/trinidad" > <jsp:directive.page contentType="text/html;charset=utf-8"/> <f:view> <tr:document title="Apache Trinidad Demo Index"> <tr:form> <tr:panelFormLayout> <tr:inputText> <tr:validateLength minimum="2"/> </tr:inputText> <tr:commandButton text="Go" /> </tr:panelFormLayout> </tr:form> </tr:document> </f:view> </jsp:root> Next step is checking your WAR w/ updated JARs.
        Hide
        Matthias Weßendorf added a comment -

        look, it works

        Show
        Matthias Weßendorf added a comment - look, it works
        Hide
        Matthias Weßendorf added a comment -

        I saw the problem in 1.2.9;
        this is not a problem in 1.2.10

        Show
        Matthias Weßendorf added a comment - I saw the problem in 1.2.9; this is not a problem in 1.2.10
        Hide
        Stephen Friedrich added a comment -

        Thanks Matthias for caring about this.
        I'm sorry to say that the strange error message (don't enter fewer than 0 characters) when using server side validation has not been fixed in the current svn version.

        Also, I checked the PPR bugs in TRINIDAD-1130 (marked as fixed in 1.2.9): Those bugs are also still happening in latest svn.

        Show
        Stephen Friedrich added a comment - Thanks Matthias for caring about this. I'm sorry to say that the strange error message (don't enter fewer than 0 characters) when using server side validation has not been fixed in the current svn version. Also, I checked the PPR bugs in TRINIDAD-1130 (marked as fixed in 1.2.9): Those bugs are also still happening in latest svn.
        Hide
        Matthias Weßendorf added a comment -

        entered "1" and got an error (as expected)

        Show
        Matthias Weßendorf added a comment - entered "1" and got an error (as expected)
        Hide
        Matthias Weßendorf added a comment -

        entered "1234" and got NO! error (as expected)

        Show
        Matthias Weßendorf added a comment - entered "1234" and got NO! error (as expected)
        Hide
        Matthias Weßendorf added a comment -

        Bug: Field is always required, even when set to false via PPR. =>
        I noticed it has changed (the required is removed, when clicking the checkbox)

        Bug: inputText looses its value when switching from disabled to not-disabled.
        I saw as well.

        Can you please keep these bugs separate ? It is pretty confusing to discuss
        several (not related) things in one bug ?

        Regarding:
        Bug: inputText looses its value when switching from disabled to not-disabled.
        Can you open a ticket ?

        Show
        Matthias Weßendorf added a comment - Bug: Field is always required, even when set to false via PPR. => I noticed it has changed (the required is removed, when clicking the checkbox) Bug: inputText looses its value when switching from disabled to not-disabled. I saw as well. Can you please keep these bugs separate ? It is pretty confusing to discuss several (not related) things in one bug ? Regarding: Bug: inputText looses its value when switching from disabled to not-disabled. Can you open a ticket ?
        Hide
        Stephen Friedrich added a comment -

        > entered "1" and got an error (as expected)

        Yes, but please do have a close look at the screenshot "server-side1.PNG" you uploaded yourself.
        It shows exactly the problem that I mentioned right from the start:
        "Server side validation works in principal, but spits out an incorrect message when the validation (correctly) fails: "Enter 0 or more characters, not fewer.""

        You might just as well call that message funny or stupid, but it will definitely confuse users when they are told not to enter fewer than zero characters.

        > I noticed it has changed (the required is removed, when clicking the checkbox)
        Yes, the icon is removed, but try to submit with an empty value and validation fails and tells you you must enter a value.

        Show
        Stephen Friedrich added a comment - > entered "1" and got an error (as expected) Yes, but please do have a close look at the screenshot "server-side1.PNG" you uploaded yourself. It shows exactly the problem that I mentioned right from the start: "Server side validation works in principal, but spits out an incorrect message when the validation (correctly) fails: "Enter 0 or more characters, not fewer."" You might just as well call that message funny or stupid, but it will definitely confuse users when they are told not to enter fewer than zero characters. > I noticed it has changed (the required is removed, when clicking the checkbox) Yes, the icon is removed, but try to submit with an empty value and validation fails and tells you you must enter a value.
        Hide
        Matthias Weßendorf added a comment -

        Stephen, I am sorry. I found the issue.
        We pass the MAX into the message.... I am sorry, I haven't watched the pic close enough.

        regarding the other issues, can you open separate bugs on that?

        Show
        Matthias Weßendorf added a comment - Stephen, I am sorry. I found the issue. We pass the MAX into the message.... I am sorry, I haven't watched the pic close enough. regarding the other issues, can you open separate bugs on that?
        Hide
        Stephen Friedrich added a comment -

        Thanks Matthias, I created TRINIDAD-1198 and TRINIDAD-1199 for the PPR problems, so we can continue any necessary discussion there.

        Show
        Stephen Friedrich added a comment - Thanks Matthias, I created TRINIDAD-1198 and TRINIDAD-1199 for the PPR problems, so we can continue any necessary discussion there.

          People

          • Assignee:
            Matthias Weßendorf
            Reporter:
            Stephen Friedrich
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development