This chapter is from the book
This chapter is from the book
This chapter is from the book
Input-Data Validation
Business applications need to validate user input to ensure that entered data is valid, meaningful, and correct with regard to a particular data type. For example, when users enter an email address, the application must validate it to ensure that it is well formed. Other examples are checking that a required field is not empty or checking that a string is shorter than a fixed number of characters or checking that a date is earlier than another one. The main reason for this is that the back-end SQL Server database cannot accept invalid data, and therefore validation is important so that no errors occur when sending data to storage. As a developer, you write validation rules, which are procedures ensuring that data adheres to specific requirements. In other development environments (including Visual Studio 2010), you must write validation rules on your own for every single column in a table. Visual Studio LightSwitch offers a built-in validation mechanism that does most of the work for you, as explained in the following subsections.
Required Fields Validation
Probably the most common requirement in data validation is checking that a required field is neither null nor empty. Visual Studio LightSwitch makes this easy because the generated applications implement a built-in mechanism that automatically checks for empty fields and notify the user about the error. For instance, when you run the Contacts Manager application and you attempt to save changes by leaving the Last Name field empty, the application surrounds the field with a red border and tells you that an error must be fixed before saving changes, as shown in Figure 3.37.
){kind=link}
)
Figure 3.37. The validation fails and the user interface notifies the user.
By clicking the error message, you can get detailed information about the issue that caused the error. In this particular case, the user is informed that the Last Name value cannot be null, as shown in Figure 3.38.
){kind=link}
)
Figure 3.38. Getting detailed information about the error.
It is important to understand that the error message is not raised by the user interface. Instead, it is raised by the entity, and the user interface is responsible for catching the error, presenting it to the user, and ensuring that validation issues are fixed before saving changes. Entities provide the actual validation mechanism by implementing built-in validation rules.
You can override the default behavior by writing custom validation rules, as described in Chapter 5, “Customizing Data Validation.” For now, focus on the fact that (without writing a single line of code) you have a fully functional, built-in data validation mechanism, which ensures that the user enters correct data without writing a single line of code.
String-Length Validation
Another common requirement in data validation is ensuring that a string is shorter than a fixed number of characters. The default length for the String data type in LightSwitch is 255, but you can make this larger or smaller.
Sometimes this limit is unnecessarily high, so you may decide to reduce the maximum length of a string. For example, the name of a country will never be 255 characters long, so you might want to limit user input for a country name to 50 characters maximum. To accomplish this, you first open the Entity Designer and select the property for which you want to edit validation. Continuing with the Contacts Manager application, select the Country property. Then, open the Properties window and locate the Validation group.
To shorten the maximum string length, you just change the value of the Maximum Length text box from 255 to the desired value (to 50 in our example). Figure 3.39 shows what the box looks like after the change. If you previously entered some string longer than the new limit, you get a warning message about data truncation.
){kind=link}
Figure 3.39. Changing a string’s maximum length.
Now run the application and, in the Country field, try to write a string longer than 50 characters. At this point, you will get a validation error informing you that the entered string is longer than allowed.
This ensures that the validation rule is respected, keeping the user interface’s behavior consistent. Figure 3.40 shows this validation scenario.
){kind=link}
)
Figure 3.40. Strings greater than the maximum length are not allowed.
Date Validation
The LightSwitch infrastructure provides default validation mechanisms for the Date type, as well. To understand how this works, open the Table Designer and add a new property named Anniversary, of type Date, not required. At this point, open the Properties window and locate the Validation group shown in Figure 3.41.
){kind=link}
Figure 3.41. The Validation group for properties of type Date.
It is a good idea to provide a suitable range, from the minimum to the maximum value. So, replace the Minimum Value content with 1/1/1920 and the Maximum Value content with 12/31/2000. This will prevent users from adding people born before January 1, 1920 and after December 31, 2000. Next, following the instructions described earlier in the “Adding and Removing Data” section, open the Screen Designer for the CreateNewContact screen and drag the Anniversary item onto the designer surface. Notice that when you add items of type Date, LightSwitch, by default, wraps them via a DatePicker control. This control displays a calendar that allows easy selection of a date (with just a single click).
Now run the application and try to specify an out-of-range date in the Anniversary field. Again, the application shows validation errors explaining the details, as shown in Figure 3.42.
){kind=link}
)
Figure 3.42. Default validation results against items of type Date.
By taking advantage of the LightSwitch built-in mechanism, you can perform validation against dates without writing a single line of code.
Number Validation
The LightSwitch validation mechanism also provides an easy way to validate numbers. This kind of validation is typically used to check whether a number falls within a specified range. This applies to the following types:
- Integer numbers, meaning Short Integer, Integer, and Long Integer data types
- Decimal numbers, meaning the Decimal data type
- Double precision numbers, meaning the Double data type
To understand how it works, consider the Age property, of type Integer, in the Contact entity of the Contacts Manager application.
Earlier, we decided that only dates between 1920 and 2000 will be accepted, so the person’s age must be within a range of 80 years. If we consider that at the moment when this chapter is being written we are in 2010, according to the dates range, the person cannot be younger than 10 and cannot be older than 90. With that said, open the Entity Designer for the Contact entity, and then select the Age property. Then open the Properties window. Locate the Validation group and replace the content of the Minimum Value and Maximum Value (empty by default) fields, respectively, with 10 and 90.
If you now run the application and try to enter a value for the Age field that does not fall within the expected range, you get a validation error, as shown in Figure 3.43.
){kind=link}
)
Figure 3.43. Validation fails because the numbers do not fall within the expected range.
Notes About Decimal Numbers
Numbers of type Decimal provide two additional properties for validation: Precision and Scale. The first one represents the maximum number of digits for the value in the entire field, including digits that are both on the left and on the right of the decimal point. Scale allows you to specify the number of digits to the right of the decimal point.