Learning Rails: Live Edition

Managing Secrets

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

The :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 :message to go with your validation. If the validation fails, the user sees the :message. The code below adds a message to the test for :secret’s presence:

# 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 all :secrets are created equal. Another set of validations will test the actual content of :secret, as shown here:

# 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 ...