Tapestry 5
  1. Tapestry 5
  2. TAP5-520

Using regular expressions with the @Validate annotation causes odd parse errors if the regexp includes common characters (including commas)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.0.18
    • Fix Version/s: 5.1.0.1
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      Try adding this field to your form:

      @Validate("regexp=^([a-zA-Z0-9]

      {2,4}

      )+$")
      private String somefield;

      Page will fail to render with exception saying:

      Render queue error in BeginRender[mypage.somefield]: Failure reading parameter 'validate' of component mypage.somefield: Coercion of ^([a-zA-Z0-9]{2 to type java.util.regex.Pattern (via String --> java.util.regex.Pattern) failed: Unclosed counted closure near index 15 ^([a-zA-Z0-9]{2 ^

        Issue Links

          Activity

          Hide
          Ulrich Stärk added a comment -

          I bet this is because tapestry thinks that after the comma, a new validator will follow. Can't you rewrite your regexp to not contain the

          {2,4}

          constraint? Is that necessary at all with the + quantifier in place?

          Show
          Ulrich Stärk added a comment - I bet this is because tapestry thinks that after the comma, a new validator will follow. Can't you rewrite your regexp to not contain the {2,4} constraint? Is that necessary at all with the + quantifier in place?
          Hide
          Mike D Pilsbury added a comment -

          I meant to create a bug for this a couple of months ago but forgot, so I'm glad that someone else has encountered it.

          Even if it could be worked around in this particular regex, I think that the restriction still needs to be addressed; it's not always going to be easy to work around. Perhaps a comma in the regex could be allowed to be escaped in some way?

          Show
          Mike D Pilsbury added a comment - I meant to create a bug for this a couple of months ago but forgot, so I'm glad that someone else has encountered it. Even if it could be worked around in this particular regex, I think that the restriction still needs to be addressed; it's not always going to be easy to work around. Perhaps a comma in the regex could be allowed to be escaped in some way?
          Hide
          Konstantin Miklevskiy added a comment -

          Found an older issue with the same problem.
          It was closed with:
          http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/TextField.html

          See in the end of the page:
          cardnumber-regexp-message=Credit Card numbers consist of 16 digits
          cardnumber-regexp=
          d

          {4}(\\-?
          d{4}

          )

          {3}

          In properties file there are no limitations on regexp syntax.

          Show
          Konstantin Miklevskiy added a comment - Found an older issue with the same problem. It was closed with: http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/TextField.html See in the end of the page: cardnumber-regexp-message=Credit Card numbers consist of 16 digits cardnumber-regexp= d {4}(\\-? d{4} ) {3} In properties file there are no limitations on regexp syntax.
          Hide
          Igor Drobiazko added a comment -

          Reopened. This is still a bug. One should be able to use commas inside @Validate("regexpr=********"). I will have a look into this.

          Show
          Igor Drobiazko added a comment - Reopened. This is still a bug. One should be able to use commas inside @Validate("regexpr=********"). I will have a look into this.
          Hide
          Howard M. Lewis Ship added a comment -

          Workaround: put the regular expression in your message catalog, i.e.

          somefield-regexp=^([a-zA-Z0-9]

          {2,4}

          )+$

          Show
          Howard M. Lewis Ship added a comment - Workaround: put the regular expression in your message catalog, i.e. somefield-regexp=^( [a-zA-Z0-9] {2,4} )+$
          Hide
          Howard M. Lewis Ship added a comment -

          I'd like to see this closed as "invalid" or "won't fix" ... but that's up to Igor as he's taken ownership.

          Show
          Howard M. Lewis Ship added a comment - I'd like to see this closed as "invalid" or "won't fix" ... but that's up to Igor as he's taken ownership.
          Hide
          Igor Drobiazko added a comment -

          Why "invalid" or "won't fix"? This is a bug. I have already a fix using positive and negative lookahead. Was just thinking about test cases. Shall I commit the fix?

          Show
          Igor Drobiazko added a comment - Why "invalid" or "won't fix"? This is a bug. I have already a fix using positive and negative lookahead. Was just thinking about test cases. Shall I commit the fix?
          Hide
          DI Florian Hackenberger added a comment -

          @Howard: Could you please re-open. This bug is an issue with ValidatorMacro definitions, as there does not seem to be a way to put them into the message catalogue.

          Show
          DI Florian Hackenberger added a comment - @Howard: Could you please re-open. This bug is an issue with ValidatorMacro definitions, as there does not seem to be a way to put them into the message catalogue.

            People

            • Assignee:
              Igor Drobiazko
              Reporter:
              Konstantin Miklevskiy
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development