Java Reference
In-Depth Information
A Note About Trimming Input
After some discussion, the Stripes community agreed that user
input should be trimmed before validating. This makes vali-
dations such as required fields, minimum length, and so on,
behave as most developers expect: entering two spaces in a
required field should not be valid, and it shouldn't pass a
min-
length=2
validation.
Because trimming the input is so often desirable, it is the default
behavior in Stripes. You can disable trimming for a field by anno-
tating it with
@Validate(trim=false)
.
Credit Card Numbers
CreditCardTypeConverter
checks that the input could be a valid credit
card number, without actually connecting to anything to check whether
an account with that number actually exists. Here's what the type con-
verter does:
• Starts by removing all nondigit characters from the input
• Checks that the card corresponds to AMEX, Diners Club, Discover
Card, enRoute, JCB, MasterCard, or Visa, based on the prefixes
and the number of digits that these cards use
• Validates the Luhn algorithm
4
on the number
CreditCardTypeConverter
is similar to
EmailTypeConverter
in that it val-
idates the input without converting it to a different type. To use it,
just add
@Validate(converter=CreditCardTypeConverter.class)
on the “Credit
card number” field.
How Stripes Processes Built-in Validations
Now that we've seen examples of each built-in validation, let's take a
closer look at how Stripes executes these validations. I've illustrated
on a list of fields, which initially contains every field. After performing
a validation, only the fields that are valid are kept in the list for the
next validation. The validations are arranged in order such that later
validations are worth running only if previous validations have passed.
Validation errors are accumulated and made available for the JSP to
display with <s:errors/>.
4.
Search WWH ::
Custom Search