Form validations: a case study
There may be times that you need to validate the data that the users of your program enter before allowing them to move forward. The simplest validation, making sure a field is not empty, is already built into GuidedTrack’s questions (you can override this by using *blank). If you require that the input is a number, use *type: number. We are now going to explore how to create validations that meet your own criteria.
Let’s say that you have created a survey that requires your participants to be 18 or more. Additionally, it’s highly unlikely that they will be older than 110, so any number greater than that is most likely a typo. Here’s how you can control that the field age is between those two numbers:
>>age = 0
*while: age > 110 or age < 18
*question: What is your age?
*save: age
*type: number
*if: age > 110 or age < 18
Sorry, {age} is not a valid age for this survey!
What about ensuring that an email address has the format xxx@xxx.xx? You can use the search bar to find the public program email format validation, which takes a given email and check that it contains the characters “@” and “.” in the correct order, along with the required number characters for the email to be valid. This program outputs variable out_isValidEmail, with value 1 if the email is valid, and 0 if it’s not. Here is how you would add this validation to your program:
*label: emailRequest
*question: Please, enter your email:
*save: email
*default: email
>>in_emailToCheck = email
*program: email format validation - public
*if: out_isValidEmail = 0
The format of your email is not correct. Please enter it again:
*classes: alert bg-danger
*goto: emailRequest
It is often a good idea to let the users of your program know what they typed so they can see where the error is. In the first example we showed you, we did it by including what they typed in the error message. In the second example we’re using the *default keyword. The first time that the question is asked, the email box will appear empty but if the validation fails and they go back to the same question, the value they entered will appear inside the box. That way they can either modify what they entered, or delete it and type in something completely new.
Additionally, on this second example we have used *classes to highlight the error message with a red background.
You can also validate multiple fields being displayed together in the same *page. The code below generates a sample contact form to gather a user’s name, US phone number and email address. The email format is validated as described before, and the *placeholder nudges the user to enter their number with the format (XXX) XXX-XXXX, but the validation will succeed as long as the user enters 10 digits, spaces, hyphens, and parentheses. If the latter are used, they must be at the beginning of the number, containing a three digit code.
>> name = ""
>> phone = ""
>> email = ""
*label: askEmailAndPhone
*page
--If the variable in_phoneToCheck exists, it's because they are returning to this page because a validation failed
*if: in_phoneToCheck
--Display validation errors
*if: out_isValidPhoneNumber = 0
The phone */{phone}/* is invalid. Please enter it again with the format (XXX) XXX - XXXX
*classes: alert alert-danger
*if: out_isValidEmail = 0
The email */{email}/* is invalid. Please enter it again.
*classes: alert alert-danger
*question: Name:
*save: name
*default: name
*question: Phone:
*save: phone
*placeholder: e.g., (123) 456 - 7890
*default: phone
*question: Email:
*save: email
*default: email
--phone number validation
>>in_phoneToCheck = phone
*program: US phone number format validator - public
--email format validation
>>in_emailToCheck = email
*program: email format validation - public
*if: out_isValidPhoneNumber = 0 or out_isValidEmail = 0
*goto: askEmailAndPhoneAnd here’s what a user would see if they mistype the phone and the email:
