Wicket
  1. Wicket
  2. WICKET-1310

StringValidator.maximumLength should automatically add maxlength html attribute

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.3.1
    • Fix Version/s: 6.0.0-beta1
    • Component/s: None
    • Labels:
      None

      Description

      Validating max length of strings should not require a round trip to the server. adding the html attribute to forms will prevent data entry on the client side.

      I'm manually doing this as part of the wicketstuff-hibernate project, but it would be great to just have this built into wicket.
      http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/src/main/java/org/wicketstuff/hibernate/annotation/HibernateAnnotationComponentConfigurator.java?view=markup

      I understand that currently validators can be used independently of Wicket and don't know about components or behaviors, but i'm recommending this be changed. Wicket is a web framework, not a validation library. If i want a portable validation library, I'll use commons-validation, not wicket. So, the validators should be web validators and be able to modify components or render custom javascript to help with web validation.

      FYI: tapestry does it! =)

      1. patch.txt
        1 kB
        Ryan Sonnek
      2. WICKET-1310.patch
        5 kB
        Attila Király

        Activity

        Hide
        Attila Király added a comment -

        In the upcoming 1.5 StringValidator extends Behavior so it would be a nice addition to have this feature now.

        Attaching a patch against current trunk that modifies ExactLengthValidator, LengthBetweenValidator and MaximumLengthValidator so they add automatically a "maxlength" attribute to the attached component's tag.

        By default they will only add it to "input" tags but with a special constructor this restriction can be lifted. This can be useful because in Html5 textarea has "maxlength" attribute too.

        Show
        Attila Király added a comment - In the upcoming 1.5 StringValidator extends Behavior so it would be a nice addition to have this feature now. Attaching a patch against current trunk that modifies ExactLengthValidator, LengthBetweenValidator and MaximumLengthValidator so they add automatically a "maxlength" attribute to the attached component's tag. By default they will only add it to "input" tags but with a special constructor this restriction can be lifted. This can be useful because in Html5 textarea has "maxlength" attribute too.
        Hide
        Igor Vaynberg added a comment -

        Ryan,
        right, thus you patch should include a check for the html tag.

        Show
        Igor Vaynberg added a comment - Ryan, right, thus you patch should include a check for the html tag.
        Hide
        Ryan Sonnek added a comment -

        Timo,
        I completely disagree. if you're using standard text fields, it makes absolute sense to use the maxlength attribute. It's the whole point of the attribute! This attribute provides the best user experience possible with no validation round trips and page refreshing required. Sure you can use AJAX, but the maxlength attribute is the best "out of the box" experience possible.

        No, it should not be optional. It should be the default behavior and if you want other behavior, you should write your own validator. Seriously, the string length validator is like 20 lines of code!

        Show
        Ryan Sonnek added a comment - Timo, I completely disagree. if you're using standard text fields, it makes absolute sense to use the maxlength attribute. It's the whole point of the attribute! This attribute provides the best user experience possible with no validation round trips and page refreshing required. Sure you can use AJAX, but the maxlength attribute is the best "out of the box" experience possible. No, it should not be optional. It should be the default behavior and if you want other behavior, you should write your own validator. Seriously, the string length validator is like 20 lines of code!
        Hide
        Ryan Sonnek added a comment -

        Igor,
        Looks like textarea doesn't support the maxlength attribute. That sucks...
        http://www.w3.org/TR/html4/interact/forms.html#h-17.7

        Show
        Ryan Sonnek added a comment - Igor, Looks like textarea doesn't support the maxlength attribute. That sucks... http://www.w3.org/TR/html4/interact/forms.html#h-17.7
        Hide
        Timo Rantalaiho added a comment -

        Likewise, sometimes even for TextField you want to allow the user to enter the whole input but show that she must shorten it. Take for example a case where the user pastes a long message from somewhere to a field that is used to enter text of an SMS message, max 160 characters. Then it's a lot better to show the whole input and an (Ajax / Javascript) error message right away to let the user shorten the message, instead of just cutting it at 160 characters.

        So if something like this is done, it should be optional.

        Show
        Timo Rantalaiho added a comment - Likewise, sometimes even for TextField you want to allow the user to enter the whole input but show that she must shorten it. Take for example a case where the user pastes a long message from somewhere to a field that is used to enter text of an SMS message, max 160 characters. Then it's a lot better to show the whole input and an (Ajax / Javascript) error message right away to let the user shorten the message, instead of just cutting it at 160 characters. So if something like this is done, it should be optional.
        Hide
        Igor Vaynberg added a comment -

        why would i want maxlength attribute added to my textareas?

        Show
        Igor Vaynberg added a comment - why would i want maxlength attribute added to my textareas?
        Hide
        Ryan Sonnek added a comment -

        attaching patch

        Show
        Ryan Sonnek added a comment - attaching patch
        Hide
        Johan Compagner added a comment -

        i think an interface like:

        IBehaviorContributer

        { getBehavior()}

        that an IValidatior can implement is the best way to go then.

        This way IValidators can just be still decoupled but can be coupled if they want.
        (i still find the coupling not that bad by the way it is not that IValidator is NOT in the wicket.jar....) So even for reusing across tiers you still need to have the wicket web framework jar there..

        Show
        Johan Compagner added a comment - i think an interface like: IBehaviorContributer { getBehavior()} that an IValidatior can implement is the best way to go then. This way IValidators can just be still decoupled but can be coupled if they want. (i still find the coupling not that bad by the way it is not that IValidator is NOT in the wicket.jar....) So even for reusing across tiers you still need to have the wicket web framework jar there..
        Hide
        Ryan Sonnek added a comment -

        Johan's suggestion sounds like a good compromise. Keep the interfaces separate, but allow for Validators to optionally implement the behavior interface to contribute markup to the component.

        Show
        Ryan Sonnek added a comment - Johan's suggestion sounds like a good compromise. Keep the interfaces separate, but allow for Validators to optionally implement the behavior interface to contribute markup to the component.
        Hide
        Igor Vaynberg added a comment -

        i do not like recoupling our validators again. in large apps validation is reusable, a service can be accessed from a web ui or a remote call. the decoupled validators allow all this validation logic to be reused across these tiers - which for larger apps is very important. i am using this in practice and it is imho indispensable..

        so a big -1 on coupling it again. what you want can.should be a feature, but it can be accomplished by treating ibehavior as a mixin.

        Show
        Igor Vaynberg added a comment - i do not like recoupling our validators again. in large apps validation is reusable, a service can be accessed from a web ui or a remote call. the decoupled validators allow all this validation logic to be reused across these tiers - which for larger apps is very important. i am using this in practice and it is imho indispensable.. so a big -1 on coupling it again. what you want can.should be a feature, but it can be accomplished by treating ibehavior as a mixin.
        Hide
        Johan Compagner added a comment -

        we already had some discussion for this to also let validatiors be behaviours

        I guess for 1.4 we need to make a discussion for this.

        Show
        Johan Compagner added a comment - we already had some discussion for this to also let validatiors be behaviours I guess for 1.4 we need to make a discussion for this.

          People

          • Assignee:
            Igor Vaynberg
            Reporter:
            Ryan Sonnek
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development