As in all cases of designing a complex system, no matter if a new building, a new space shuttle, a new computer or a new software application is to be designed, an architecture provides a kind of master plan for defining the structure of the system. Any good architecture is based on the fundamental engineering principle of separation of concerns, which helps in managing complexity by breaking a system down into smaller, functionally defined parts such that their interdependencies are minimized, keeping the more fundamental parts independent of the less fundamental parts. Such an architecture also makes it easier to develop, or source, and update certain system parts independently of others.

For using the functionality of mODELcLASSjs in your app, you have to include its code, either by downloading mODELcLASS.js to the lib folder and use a local script loading element like the following:

<script src="lib/mODELcLASSjs.js"></script>

or with the help of a remote script loading element like the following:

<script src="http://web-engineering.info/tech/JsMODELvIEW/mODELcLASS.js"></script>

Then you can create your app's model classes (with property and method declarations) as instances of the meta-class mODELcLASS:

Book = new mODELcLASS({
  name: "Book",
  properties: {
    isbn: {range:"NonEmptyString", isStandardId: true, label:"ISBN", pattern:/\b\d{9}(\d|X)\b/, 
        patternMessage:'The ISBN must be a 10-digit string or a 9-digit string followed by "X"!'},
    title: {range:"NonEmptyString", min: 2, max: 50, label:"Title"}, 
    year: {range:"Integer", min: 1459, max: util.nextYear(), label:"Year"}
  },
  methods: {
    ...
  }
});

Notice that the declaration of a property includes the constraints that apply to it. For instance, the declaration of the property isbn includes a pattern constraint requiring that the ISBN must be a 10-digit string or a 9-digit string followed by "X".

After defining a model class, you can create new 'model objects' instantiating it by invoking its create method pre-defined by mODELcLASS:

var book1 = Book.create({isbn:"006251587X", title:"Weaving the Web", year: 2000});

You can then apply the following properties and methods, all pre-defined by mODELcLASS

The use of these mODELcLASS features is illustrated by the following examples:

console.log( book1.type.name);  // "Book"
book1.set("year", 1001);  // "IntervalConstraintViolation: Year must not be smaller than 1459"
book1.set("year", 2001);  // change the year to 2001
console.log( book1.isInstanceOf( Book));  // true
console.log( book1.toString());  // "Book{ isbn:"006251587X", ...}"

You can also invoke the generic check method provided by mODELcLASS in the user interface code. For instance, for responsive validation with the HTML5 constraint validation API, you may do the following:

var formEl = document.forms["Book"];
formEl.isbn.addEventListener("input", function () {
  formEl.isbn.setCustomValidity( 
      Book.check( "isbn", formEl.isbn.value).message);
});

Here we define an event handler for input events on the ISBN input field. It invokes the setCustomValidity method of the HTML5 constraint validation API for setting a validation error message that results from invoking Book.check for validating the constraints defined for the isbn property for the user input value from the form field formEl.isbn. The check method returns a constraint violation object with a message property. If no constraint is violated, the message is an empty string, so nothing happens. Notice that you don't have to write the code of the check method, as it is pre-defined by mODELcLASSjs.

For managing data storage, a sTORAGEmANAGER object has to be created first:

storageManager = new sTORAGEmANAGER();

By default, when providing no argument in the invocation of new sTORAGEmANAGER(), data is stored locally with the help of JavaScript's Local Storage API in the form of 'stringified' JSON tables.

With the help of the created storage manager, you can then, for instance, create new model objects and store them using the storage manager's add method, like so,

storageManager.add( Book, {isbn:"006251587X",
    title:"Weaving the Web", year: 2000});

Notice that the first parameter of all data management methods is the model class concerned, which is Book in the example code.

We must not confuse the term model as used in the MVC metaphor, and adopted by many web application frameworks, and the term model as used in UML and other modeling languages. While the former refers to the model classes of an app, the latter refers to the concept of a model either as a simplified description of some part of the real world, or as a design blueprint for construction.

In model-based engineering, models are the basis for designing and implementing a system, no matter if the system to be built is a software system or another kind of complex system such as a manufacturing machine, a car, or an organisation.

In model-based software development, we distinguish between three kinds of models:

Domain models are the basis for designing a software system by making a platform-independent design model, which is in turn the basis for implementing a system by making an implementation model and encoding it in the language of the chosen platform. Concerning information modeling, we first make a (conceptual) domain information model, then we derive an information design model from it, and finally map the information design model to a data model for the target platform. We then code this data model in the form of model classes, which are the basis for any data management user interface.

mODELcLASSjs facilitates model-based app development by allowing a direct encoding of an information design model, including subtype/inheritance relationships.

The concept of a class is fundamental in object-oriented programming. Objects instantiate (or are classified by) a class. A class defines the properties and methods for the objetcs that instantiate it.

There is no explicit class concept in JavaScript. However, classes can be defined in two ways:

Since we normally need to define class hierarchies, and not just single classes, these two alternative approaches cannot be mixed within a class hierarchy, and we have to make a choice whenever we build an app. With mODELcLASSjs, we choose the second approach with the following benefits:

These benefits come with a price: objects are created with lower performance, mainly due to the fact that Object.create is slower than new. On the other hand, for apps with lots of object creation and destruction, such as games and simulations, mODELcLASSjs provides object pools for avoiding performance problems due to garbage collection.

The properties and methods of the meta-class mODELcLASS, and the properties and methods it injects in any model class created with its create method, are listed in the following class diagram:

Figure 1.1. The meta-class mODELcLASS

Notice that in the diagram, we use the (imaginary) type mODELoBJECT for showing the pre-defined property type and several methods pre-defined for all objects that instantiate a class created with mODELcLASS. The class Book is an example of a mODELcLASS. As a subclass of mODELoBJECT, it inherits its property type and all its methods.

The values of the pre-defined property instances are maps of mODELoBJECTs representing the extension (or population) of a model class.

Any mODELcLASS has a class-level check method for validating all kinds of property constraints. Since this method can validate all properties of a model class, it takes as its first parameter the name of the property, and as its second parameter the value to be validated:

mODELcLASS.prototype.check = function (prop, val) {
  var propDeclParams = this.properties[prop],
      range = propDeclParams.range,
      min = propDeclParams.min,
      max = propDeclParams.max,
      minCard = propDeclParams.minCard,
      maxCard = propDeclParams.maxCard,
      pattern = propDeclParams.pattern,
      msg = propDeclParams.patternMessage,
      label = propDeclParams.label || prop;

Notice that the definition of a model class comes with a set of property declarations in properties. An example of such a property declaration is the declaration of the attribute title:

title: {range:"NonEmptyString", min: 2, max: 50, label:"Title"}, 

In this example we have the property declaration parameters range, min, max and label. In lines 2-10 above, all these property declaration parameters are copied to local variables for having convenient shortcuts.

In the check method, the first check is concerned with mandatory value constraints:

  if (!propDeclParams.optional && val === undefined) {
      return new MandatoryValueConstraintViolation("A value for "+ 
          label +" is required!");	  
  }

The next check is concerned with range constraints:

  switch (range) {
  case "String":
    if (typeof( val) !== "string") {
      return new RangeConstraintViolation("The "+ label +
          " must be a string!");
    } 
    break;
  case "NonEmptyString":
    if (typeof(val) !== "string" || val.trim() === "") {
      return new RangeConstraintViolation("The "+ label +
          " must be a non-empty string!");
    }
    break;
  ...  // other cases
  case "Boolean":
    if (typeof( val) !== "boolean") {
      return new RangeConstraintViolation("The value of "+ label +
          " must be either 'true' or 'false'!");
    }
    break;
  }

Then there are several range-specific checks concerning (1) string length constraints and pattern constraints:

  if (range === "String" || range === "NonEmptyString") {
    if (min !== undefined && val.length < min) {
      return new StringLengthConstraintViolation("The length of "+
          label + " must be greater than "+ min);
    } else if (max !== undefined && val.length > max) {
      return new StringLengthConstraintViolation("The length of "+
          label + " must be smaller than "+ max);  	
    } else if (pattern !== undefined && !pattern.test( val)) {
        return new PatternConstraintViolation( msg || val +
            "does not comply with the pattern defined for "+ label);  	
    }  
  }

and (2) interval constraints:

  if (range === "Integer" || range === "NonNegativeInteger" || 
      range === "PositiveInteger") {
    if (min !== undefined && val < min) {
      return new IntervalConstraintViolation( label +
          " must be greater than "+ min);
    } else if (max !== undefined && val > max) {
      return new IntervalConstraintViolation( label +
          " must be smaller than "+ max);  	
    }
  }

Then the next check is concerned with cardinality constraints, which may apply to list-valued or map-valued properties.

  if (minCard !== undefined && 
      (Array.isArray(val) && val.length < minCard || 
       typeof(val)==="object" && Object.keys(val).length < minCard)) {
    return new CardinalityConstraintViolation(
        "A set of at least "+ minCard +" values is required for "+ label);	  
  }
  if (maxCard !== undefined && 
      (Array.isArray(val) && val.length > maxCard || 
       typeof(val)==="object" && Object.keys(val).length > maxCard)) {
    return new CardinalityConstraintViolation("A value set for "+ label + 
        " must not have more than "+ maxCard +" members!");	  
  }

The next check is concerned with uniqueness constraints, which can only be checked by inspecting the entire population of the model class. Assuming that this population has been loaded into the main memory collection modelclass.instances, the following code is used:

  if (propDeclParams.unique && this.instances) {
    keys = Object.keys( this.instances);
    for (i=0; i < keys.length; i++) {
      if ( this.instances[keys[i]][prop] === val) {
        return new UniquenessConstraintViolation("There is already a "+
            this.name +" with a(n) "+ label +" value "+ val +"!");
      }
    }
  }

Finally, the mandatory value constraints and the uniqueness constraints implied by a standard identifier declaration are checked:

  if (propDeclParams.isStandardId) {
    if (val === undefined) {
      return new MandatoryValueConstraintViolation("A value for the " +
          "standard identifier attribute "+ label +" is required!");
    } else if (this.instances && this.instances[val]) {
      return new UniquenessConstraintViolation("There is already a "+
          this.name +" with a(n) "+ label +" value "+ val +"!");	  
    }
  }

As explained above in Section 1.3, “The Model-Storage-View-Controller (MSVC) architecture pattern”, mODELcLASSjs is using a data mapper approach for separating model classes and storage management. A mODELcLASSjs application creates a sTORAGEmANAGER object at application start-up time, typically in some piece of controller code, by providing parameter values for a storage adapter (such as local storage or back-end storage with MySQL).

The storage manager has a list of available storage adapters, one of which is assigned as the currently used adapter. Each available storage adapter (such as LocaStorage or MySQL in the diagram below) implements the CRUD methods specified in the abstract class AbstractStorageAdapter.

Figure 1.2. The sTORAGEmANAGER classes

We now show how to code the ten integrity constraints defined by the design model shown in Figure 2.1 above.

This leads to the following definition of the model class Book :

Book = new mODELcLASS({
  name: "Book",
  properties: {
    isbn: {range:"NonEmptyString", isStandardId: true, label:"ISBN", pattern:/\b\d{9}(\d|X)\b/, 
        patternMessage:"The ISBN must be a 10-digit string or a 9-digit string followed by 'X'!"},
    title: {range:"NonEmptyString", max: 50},
    year: {range:"Integer", min: 1459, max: util.nextYear()},
    edition: {range:"PositiveInteger", optional: true}
  }
});

For such a model class definition, mODELcLASSjs provides generic data management operations (Book.add, Book.update, Book.destroy, etc.) as well as property checks and setters (Book.check and bookObject.set).

The MVC folder structure of this project is the same as discussed in the plain JavaScript validation app tutorial. Also, the same library files are used.

The start page of the app first takes care of the page styling by loading normalize.css and our main.css file with the help of the two link elements (in lines 6 and 7), then it loads the mODELcLASSjs library file, the app initialization script initialize.js from the src/ctrl folder and the model class Book.js from the src/model folder.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta charset="UTF-8" />
  <title>mODELcLASSjs Validation App</title>
  <link rel="stylesheet" type="text/css" href="../css/normalize.css" />
  <link rel="stylesheet" type="text/css" href="../css/main.css" /> 
  <script src="../mODELcLASSjs.min.js"></script>
  <script src="src/ctrl/initialize.js"></script>
  <script src="src/model/Book.js"></script>
</head>
<body>
  <h1>Example: Public Library</h1>
  <h2>mODELcLASS Validation App</h2>
  <p>This app supports the following operations:</p>
  <menu>
    <li><a href="listBooks.html">
         <button type="button">List all books</button></a></li>
    <li><a href="createBook.html">
         <button type="button">Add a new book</button></a></li>
    <li><a href="updateBook.html">
         <button type="button">Update a book</button></a></li>
    <li><a href="deleteBook.html">
         <button type="button">Delete a book</button></a></li>
    <li><button type="button" onclick="Book.clearData()">
         Clear database</button></li>
    <li><button type="button" onclick="Book.createTestData()">
         Create test data</button></li>
  </menu>
</body>
</html>

The app initialization script initialize.js first defines the app's namespaces and then creates a local storage manager. It also defines a method for creating test data:

// main namespace pl = "public library"
var pl = {model:{}, view: {}, ctrl:{}};
// define a localStorage manager
pl.ctrl.storageManager =  new sTORAGEmANAGER();
/**
 *  Create and save test data
 */
pl.ctrl.createTestData =  function () {
  pl.ctrl.storageManager.add( Book, {isbn:"006251587X",
      title:"Weaving the Web", year: 2000, edition: 2});
  pl.ctrl.storageManager.add( Book, {isbn:"0465026567",
      title:"Gödel, Escher, Bach", year: 1999});
  pl.ctrl.storageManager.add( Book, {isbn:"0465030793",
      title:"I Am A Strange Loop", year: 2008});
};

The user interface (UI) is the same as explained in the plain JavaScript validation app tutorial. There is only one difference. For responsive constraint validation, where input event handlers are used to check constraints on user input, now the generic Book.check function is used, as shown in the following code fragment of the setupUserInterface method from src/view/createBook.js:

pl.view.createBook = {
  setupUserInterface: function () {
    var formEl = document.forms['Book'],
        submitButton = formEl.commit;
    submitButton.addEventListener("click", 
        this.handleSubmitButtonClickEvent);
    formEl.isbn.addEventListener("input", function () { 
        formEl.isbn.setCustomValidity( 
            Book.check("isbn", formEl.isbn.value).message);
    });
    formEl.title.addEventListener("input", function () { 
        formEl.title.setCustomValidity( 
            Book.check("title", formEl.title.value).message);
    });
   ...
  },
};

While the validation on user input enhances the usability of the UI by providing immediate feedback to the user, validation on form submission is even more important for catching invalid data. Therefore, the event handler handleSubmitButtonClickEvent() performs the property checks again, as shown in the following program listing:

handleSaveButtonClickEvent: function () {
  var formEl = document.forms['Book'], slots = {};
  // create error messages in case of constraint violations
  Object.keys( Book.properties).forEach( function (prop) {
    var errMsg="";
    slots[prop] = formEl[prop].value;
    errMsg = Book.check( prop, slots[prop]).message;
    formEl[prop].setCustomValidity( errMsg);
  });
  // save the input data only if all of the form fields are valid
  if (formEl.checkValidity()) {
    pl.ctrl.storageManager.add( Book, slots);
  }
}

You can run the mODELcLASS validation app from our server or download the code as a ZIP archive file.

After eliminating the repetitive code structures (called boilerplate code) needed in the model layer for constraint validation and for the data storage management methods, there is still a lot of boilerplate code needed in the UI. In a follow-up article of our tutorial series, we will present an approach how to avoid this UI boilerplate code.