While we’d like visitors to enter their names, it’s usually best not to be too picky
about names, because they come in so many varieties. On the other hand, the
:secret field is ripe with opportunities for demanding
expectations. Along the way, this example will demonstrate how you can use multiple
validations on the same field in sequence.
Customizing the Message
:secret field needs to be present. Sometimes,
though, it’s worth telling a user why a particular mistake matters rather than just
insisting, “field_name can’t be
blank.” Rails makes that easy to do by letting you specify a
to go with your validation. If the validation fails, the user sees the
:message. The code below adds a message to the test
# secret is also mandatory, but let's alter the default Rails message to be # more friendly validates_presence_of :secret,
:message => "must be provided so we can recognize you in the future"
If the user leaves the
:secret field blank,
they’ll see a custom error message as shown in Figure 7-4.
Even if the user provides a
:secret, though, not
:secrets are created equal. Another set of
validations will test the actual content of
# ensure secret has enough letters, but not too many validates_length_of :secret, :in => 6..24 # ensure secret contains at least one number validates_format_of :secret, :with => /[0-9]/, :message => "must contain at least one number" # ensure secret contains at least one upper case ...