Release: Validation Plugin 1.3

A new release of the validation plugin is done, now at version 1.3. This release adds five more localizations and fixes a few bugs, eg. “asdf” is not a valid creditcard number anymore.

Major improvements went into validating a form without triggering UI feedback and batch adding and removing of rules.

The complete list of changes:

  • Fixed invalid-form event, now only triggered when form is invalid
  • Added spanish (es), russian (ru), portuguese brazilian (ptbr), turkish (tr), and polish (pl) localization
  • Added removeAttrs plugin to facilate adding and removing multiple attributes
  • Added groups option to display a single message for multiple elements, via groups: { arbitraryGroupName: “fieldName1 fieldName2[, fieldNameN” }
  • Enhanced rules() for adding and removing (static) rules: rules(“add”, “method1[, methodN]”/{method1:param[, method_n:param]}) and rules(“remove”[, “method1[, method_n]”)
  • Enhanced rules-option, accepts space-seperated string-list of methods, eg. {birthdate: “required date”}
  • Fixed checkbox group validation with inline rules: As long as the rules are specified on the first element, the group is now properly validated on click
  • Fixed #2473, ignoring all rules with an explicit parameter of boolean-false, eg. required:false is the same as not specifying required at all (it was handled as required:true so far)
  • Fixed #2424, with a modified patch from #2473: Methods returning a dependency-mismatch don’t stop other rules from being evaluated anymore; still, success isn’t applied for optional fields
  • Fixed url and email validation to not use trimmed values
  • Fixed creditcard validation to accept only digits and dashes (“asdf” is not a valid creditcard number)
  • Allow both button and input elements for cancel buttons (via class=”cancel”)
  • Fixed #2215: Fixed message display to call unhighlight as part of showing and hiding messages, no more visual side-effects while checking an element and extracted validator.checkForm to validate a form without UI sideeffects
  • Rewrote custom selectors (:blank, :filled, :unchecked) with functions for compability with AIR

As always, feedback, via the mailing list or via donations, is welcome!


No more comments.
  1. Awesome work, Jörn!

  2. Thanks Jörn, your hard work is appreciated by many.

    I had been using Prototype and its related validation code, but moved over to jQuery and your validation plugin, and wouldn’t go back, that’s for sure!

    The only thing (that I can think of at the moment) is having some slide / fade effects on the error container etc. Just a bit of eye candy 🙂

  3. Jacob, thanks for the comment!

    Adding slide/fade animations to error messages is on the roadmap. I’m currently experimenting with a solution similar to that on Once that is stable I want to feed it back to the plugin.

    In any case, you can already use the showErrors option to implement your own message display handling.

  4. Miguel Benevides

    Anyone else having problems using jQuery v1.2.5 with the Validation plugin v1.3?

  5. Yes, 1.2.5 breaks the validation plugin. Please stick with 1.2.3 until either another core release is out or an update to the validation plugin.

  6. Tim

    I just had a look at and really like the idea of the tool tip error messages. It keeps the form nice and clean looking even when there are errors. If you get a final version similar let me know I be very interested in donating to the final soluton.

    Also have question in regards to the remote rules, as is it works perfect if the form is empty {new registration}.

    When you provide form that isn’t empty as in updating ones details, the fields email and username that have the remote rules attached to them when you submit your changes the form will not submit.

    It will submit if one changes the email or username as the form validates them and checks if they have been used. If you decide not change your email and username or even field that has the remote rule you are stuck with a form that goes no where.

    Is there a rule that if {value of field != value of field} do a remote check and if { value of field = value of field} ignore the remote rule.

    Thanks Tim

  7. Hey Tim,

    a tooltip solution similar to the registration form is in progress.

    I’ll take a look at the remote-method issue, thanks for reporting!