Chapter 6. Constraint Validation in a Plain JS Front-End App

Table of Contents

1. Introduction
2. Using the HTML5 Form Validation API
3. New Issues
4. Make a JavaScript Data Model
5. Set up the Folder Structure with Library Files
5.1. Style the user interface with CSS
5.2. Provide general utility functions and JavaScript fixes in library files
5.3. Create a start page
6. Write the Model Code
6.1. Summary
6.2. Encode the model class as a constructor function
6.3. Encode the property checks
6.4. Encode the property setters
6.5. Add a serialization function
6.6. Data management operations
7. The View and Controller Layers
7.1. The data management UI pages
7.2. Initialize the app
7.3. Initialize the data management use cases
7.4. Set up the user interface
8. Run the App and Get the Code
9. Evaluation
10. Possible Variations and Extensions
10.1. Adding an object-level custom validation function
10.2. Simplifying forms with implicit labels
11. Points of Attention
11.1. Database size and memory management
11.2. Boilerplate code
12. Quiz Questions
12.1. Question 1: Validation in Setter (1)
12.2. Question 2: Validation in Setter (2)
12.3. Question 3: Methods to Add in JS Data Model
12.4. Question 4: Implementing Constraints

1. Introduction

The minimal JavaScript front-end web application that we have discussed in Part 1 has been limited to support the minimum functionality of a data management app only. For instance, it did not take care of preventing the user from entering invalid data into the app's database. In this second part of the tutorial we show how to express integrity constraints in a JavaScript model class, and how to perform constraint validation both in the model part of the app and in the user interface built with HTML5.

We again consider the single-class data management problem that was considered in Part 1 of this tutorial. So, again, the purpose of our app is to manage information about books. But now we also consider the data integrity rules (also called 'business rules') that govern the management of book data. These integrity rules, or constraints, can be expressed in a UML class diagram as shown in Figure 6.1 below.

Figure 6.1. A platform-independent design model with the object type Book and two invariants

A platform-independent design model with the object type Book and two invariants

In this model, the following constraints have been expressed:

  1. Due to the fact that the isbn attribute is declared to be the standard identifier of Book, it is mandatory and unique.

  2. The isbn attribute has a pattern constraint requiring its values to match the ISBN-10 format that admits only 10-digit strings or 9-digit strings followed by "X".

  3. The title attribute is mandatory, as indicated by its multiplicity expression [1], and has a string length constraint requiring its values to have at most 50 characters.

  4. The year attribute is mandatory and has an interval constraint, however, of a special form since the maximum is not fixed, but provided by the calendaric function nextYear(), which we implement as a utility function.

Notice that the edition attribute is not mandatory, but optional, as indicated by its multiplicity expression [0..1]. In addition to the constraints described in this list, there are the implicit range constraints defined by assigning the datatype NonEmptyString as range to isbn and title, Integer to year, and PositiveInteger to edition. In our plain JavaScript approach, all these property constraints are encoded in the model class within property-specific check functions.

The meaning of the design model can be illustrated by a sample data population for the model class Book:

Table 6.1. Sample data for Book

ISBN Title Year Edition
006251587X Weaving the Web 2000 3
0465026567 Gödel, Escher, Bach 1999 2
0465030793 I Am A Strange Loop 2008