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 ^

        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