The basic idea around integrating left and top navigation into the app is to provide context-aware subviews that change based on the active view. For example, when we are on a list page as opposed to editing an item, we may want to show different elements in the navigation. An e-commerce site is a great example of this. Imagine Amazon's search result page and product detail page. As the context changes from a list of products to a specific product, the navigation elements that are loaded also change.

To integrate left and top navigation into Workout Builder, we have extended the app at a number of locations. To start with, look at the new routes in app.js. Some of these routes contain custom properties that are not part of the standard route configuration object created using when (https://code.angularjs.org/1.3.3/docs/api/ngRoute/provider/$routeProvider):

$routeProvider.when('/builder/workouts', {
templateUrl: 'partials/workoutbuilder/workouts.html',
controller: 'WorkoutListController',
leftNav: 'partials/workoutbuilder/left-nav-main.html',
topNav: 'partials/workoutbuilder/top-nav.html'
});

Open the index.html file and pay attention to the highlighted code:

<div class="navbar navbar-default navbar-fixed-top top-navbar">
    <!--Existing html-->
    <div id="top-nav-container" class="second-top-nav">
        <div id="top-nav" ng-include="currentRoute.topNav"></div>
    </div>
</div>
<div class="container-fluid">
  <div id="content-container" class="row">
    <div class="col-sm-2 left-nav-bar" ng-if="currentRoute.leftNav">
      <div id="left-nav" ng-include="currentRoute.leftNav"></div>
        </div>
        <div class="col-sm-10 col-sm-offset-2">
            <div id="page-content" ng-view></div>
        </div>
</div>
</div>

The index.html file has been updated and now defines three areas, one each for top and left navigation, and one for the main view.

Looking back at route configuration, the templateUrl property in the route definition references the view template that is loaded in the ng-view directive of the div element. We try to simulate something similar to what Angular does for our left and top navigation.

The value of the topNav property is used to load the top navigation view in the top-nav div element ("id = top-nav") using the ng-include directive. We do the same for left navigation too. The ng-if directive in the left-nav section is used to hide left navigation if the current route configuration does not define the leftNav property. We will shortly see how to set up the currentRoute property used in the ng-include expression mentioned previously.

With this configuration in place, we can associate different left and top navigation views with different pages. In the preceding route configuration for the workout list, the left navigation comes from left-nav-main.html and top navigation from top-nav.html. Look at the other route configuration too, to learn what other navigation templates we have configured.

The last part of this integration is setting up the currentRoute property and binding it to ng-include. Angular sets up the ng-view template using the route configuration templateUrl property, but it does not know or care about the topNav and leftNav properties that we have added. We need to write some custom code that binds the navigation URLs with the respective ng-includes directives.

To do this linkup, open root.js and add these event handler lines to RootController:

$scope.$on('$routeChangeSuccess', function (e, current, previous) {
  $scope.currentRoute = current;
});

We subscribe to the $routeChangeSuccess event raised by the $route service. As the name suggests, the event is raised when the route change is complete or the main view is loaded. The current and previous parameters are the route configuration objects for the loaded and the previous view respectively. These are the same objects that we configured inside the $routeProvider.then function. Once we assign the current object to currentRoute, it is just a matter of referencing the route properties in ng-include (currentRoute.topNav or currentRoute.leftNav) and the correct template for left and top navigation are loaded. Look at the highlighted code of the index.html file outlined previously.

The reason this event handler is in RootController is because RootController is defined outside the ng-view directive and encompasses nearly the complete index page. Hence, it is a good place to plug common functionality used across child views.

Go ahead and load the workout builder page #/builder. We will be redirected to the workouts page under #/builder. This page lists all the available workouts.

$routeProvider.when('/builder',{redirectTo:'/builder/workouts'});

The workout list page is currently empty but the left and top navigation links work. Click on the New Workout or New Exercise link on top nav and the app loads the create workout/exercise pages. The left navigation associated with the list pages (left-nav-main.html) has two links: Workouts and Exercises, to switch between the workout and exercise list.

With a little customization, we have been able to create a decent navigation system that reacts to the main view change and loads the correct views in left and top navigation. Along the same lines, we can always add footer and multiple subviews to our app if desired.

The skeleton layout, views, and navigation are now in place and it's time to add some meat to the implementation. The exercise and workout list is something that is easy to implement, so let's take that first.

The resolve property is part of the route configuration object, and provides a mechanism to pass data and/or services to a specific controller. This is the same controller that is instantiated as part of a route change (specified in the controller property of the route configuration object). The resolve object property can be one of the following:

We add a property selectedWorkout (that points to a function) to resolve an object in both routes. This function, when executed during the route change, starts the workout building process by calling the WorkoutBuilderService.startBuilding function.

For the new workout route, we do not pass any parameter:

WorkoutBuilderService.startBuilding();

For the edit route (route with :id), we pass the workout name in a route/URL:

WorkoutBuilderService.startBuilding($route.current.params.id);

The return value of selectedWorkout is the workout returned by WorkoutBuilderService.startBuilding.

Note that any function properties of the resolve object can take dependencies similar to an AngularJS controller. Have a look at the selectedWorkout declaration:

selectedWorkout: ['WorkoutBuilderService', function (WorkoutBuilderService) {

We take a dependency on WorkoutBuilderService.

Using the resolve configuration to load the selected workout has another advantage. We can handle routes that are not found.

With dynamically generated routes, there is always a chance of a route being invalid. For example, the workout edit route, such as builder/workouts/abc or builder/workouts/xyz, points to workout names (abc and xyz) that don't exist. In such a scenario, the workout builder page does not make sense.

The resolve configuration can help here. If a workout with a given name is not found, we can redirect the user back to the workout list page. Let's see how. Open app.js and add the highlighted code, to edit the workout route:

$routeProvider.when('/builder/workouts/:id', {
    //existing code
    resolve: {
      selectedWorkout: ['WorkoutBuilderService', '$route', '$location', function (WorkoutBuilderService, $route, $location) {
var workout = 
WorkoutBuilderService.startBuilding($route.current.params.id);
            if (!workout) {
                $location.path('/builder/workouts');
            }
            return workout;
        }],
    }

We try to load the workout with a specific ID (workout name) and if not found, redirect the user back to the workout list page. Since we are using the $location service, we need to add it as a dependency in the selectWorkout function.

There is another use case the resolve object can handle that involves asynchronous server interaction using promises. We will cover this scenario in the next Lesson. For now, let's continue with the WorkoutDetailController implementation.

To implement ExerciseDetailController, we inject the current workout being built using DI. We have already set up the preceding resolve object to get the workout. Add a new controller declaration to workout.js (located in the WorkoutBuilder folder under appjs) after the WorkoutListController declaration:

angular.module('WorkoutBuilder').controller('WorkoutDetailController', ['$scope', 'WorkoutBuilderService', 'selectedWorkout', function ($scope, WorkoutBuilderService, selectedWorkout) {
  var init = function () {
  $scope.workout = selectedWorkout; // Resolved workout
  };
  init();
}]);

The $scope.workout object tracks the workout we are working on.

For now, this is enough for the controller implementation. Let's update the skeleton workout builder view.

The primary form-related constructs in AngularJS are:

For the ng-model directive to work correctly, another set of directives is required, which include:

The first directive that requires our focus is the ng-model directive. Let's explore this directive and understand how it works.

One of the primary roles of the ng-model directive is to support two-way binding between user input and the underlying model. With such a setup, changes in a model are reflected in the view, and updates to the view too are reflected back on the underlying model. Most of the other directives that we have covered so far only support one-way binding from models to views. This is also due to the fact that ng-model is only applied to elements that allow user input.

The ng-model directive works with the input, textarea, and select HTML elements as these are primarily responsible for user input. Let's look at these elements in more detail.

Using ng-model with input and textarea

Open workout.html and look for ng-model. Here too, it has only been applied to HTML elements that allow user data input. These include input, textarea, and select. The workout name input setup looks like this:

<input type="text" name="workoutName" id="workout-name" ng-model="workout.name">

The preceding ng-model directive sets up a two-way binding between the input and model property workout.name.

Angular supports most of the HTML5 input types, including text, date, time, week, month, number, URL, e-mail, radio, and checkbox. This simply means binding between a model and any of these input types just works out-of-the-box.

The textarea element too works the same as input:

<textarea name="description" ng-model="workout.description" . . . > </textarea>

Here we bind textarea to workout.description. Under the cover, there are directives for each input, textarea, and select, which co-ordinates with the ng-model directive to achieve two-way binding.

Note

It is important to understand that the ng-model directive is there to update the model. When the actual update is done, it is influenced by the supporting directives: input, textarea, and select. For example, when ng-model is used with input, the change and input events (yes, input is the name of an event too) are subscribed by the input directive, and model data is updated when these events are triggered. This effectively creates a two-way binding between the model data and the HTML element on which ng-model is declared.

Why don't we verify this binding work? Add a model interpolation expression against any of the linked input such as this one:

 <input type="text" … ng-model="workout.name">{{workout.name}}

Open the workout builder page, and type something in the input, and see how the interpolation is updated instantaneously. The magic of two-way binding!

Using ng-model with select is a bit different as we can set up the select options in multiple ways.

Using ng-model with select

Let's look at how select has been set up:

<select … name="duration" ng-model="exercise.duration" 
ng-options="duration.value as duration.title for duration in durations"></select>

There are no inner option tags! Instead, there is a ng-options attribute. If you recall the ng-repeat expression, the ng-options expression looks similar. It allows us to bind an object or array to select. The ng-options directive here binds to an array, durations. The array looks like this:

$scope.durations = [{ title: "15 seconds", value: 15 },
                    { title: "30 seconds", value: 30 }, ...]

The ng-options directive supports multiple formats of data binding. The format we use is:

[selected] as [label] for [value] in array

Where:

• selected: What (duration.value) gets assigned to ng-model (exercise.duration) when the item is selected
• label: What is shown (duration.title) in the dropdown
• value: This is an item (duration) in the array that binds to a select option

The selected parameter is optional and only required if we want to set a subproperty of a selected item to ng-model, which we do want. If it sounds confusing, update the ng-options expression in the view to:

ng-options="duration.title for duration in durations"

Then, add the {{exercise.duration}} interpolation just after the select end tag (</select>). Refresh the workout builder page and try to select a time duration from the drop-down box. The interpolation value is an object instead of the integer time. See the following screenshot:

Revert the ng-options expression and try again, this time the interpolation should have the correct time duration.

Note

The ng-options directive also supports binding to an object property and multiple expression formats. Check the documentation on select to know more about these options at https://code.angularjs.org/1.3.3/docs/api/ng/directive/select

The ng-options directive gives us great flexibility when it comes to binding an object or array to select. However, we can still use the traditional option tag instead of ng-options. The same select tag if implemented with the option tag would look like this:

<select ... ng-model="exercise.duration">
  <option value="{{duration.value}}" 
    label="{{duration.title}}" 
    ng-repeat="duration in durations" 
    ng-selected="exercise.duration==duration.value">
    {{duration.title}}
  </option>
</select>

In this case, the option tags are generated using ng-repeat. Also, the ng-model directive binds to the option value property ({{duration.value}}). The ng-selected directive is used to bind the initial value of the model data to the view.

Clearly ng-options is a better alternative to option as it provides more flexibility and is a little less verbose. Given that the option tag approach only works with string values, it is always advisable to use ng-options.

Like input, select too supports two-way binding. We saw how changing select updates a model, but the model to view binding may not be apparent. To verify if a model to a view binding works, open the 7 Minute Workout app and verify the duration dropdowns. Each one has a value that is consistent with model value (30 seconds).

AngularJS does an awesome job in keeping the model and view in sync using ng-model. Change the model and see the view updated, change the view and watch the model updated instantaneously. Starting from Angular 1.3, things just got even better. In 1.3, we can even control when the updates to the view are reflected on the model.

Note

If you are using Angular 1.2.x or earlier, you can safely skip the next section.

The ng-model-options directive is pretty useful if we want to control when the model should be updated on view changes. To understand what it has to offer, let's try out some of its options.

Let's take the same workoutName input and try it out. Update the workoutName input to this:

<input type="text" … ng-model="workout.name" 
  ng-model-options="{updateOn:'blur'}">{{workout.name}}

Open the workout builder page and enter some content in workoutName input. Model interpolation does not update as we type, but only when we leave the input—interesting!

The updateOn expression allows us to customize on what event model data should be updated, and we can configure multiple events here (space-delimited).

Change previous updateOn to:

ng-model-options="{updateOn:'blur mouseleave'}"

The model is now updated on blur, as well as when the mouse leaves the input. To experience the mouseleave event, start typing with the mouse cursor inside the workoutName input and then move the mouse out. The model interpolation changes to reflect what we have typed!

Another interesting feature that ng-model-options provides is what we call a debounce effect. Again, the best way to learn about it is by using it. Update the ng-model-options value to this:

ng-model-options = "{updateOn:'default blur'
  , debounce: {'default': 1000, 'blur': 0}}"

Refresh the workout builder page and change the workout name. The model does not get updated as you type, but it eventually does (after one second) without us leaving the field.

This debounce mechanism dictates how long Angular waits after an event to update the underlying model. The default keyword previously used is a special string that signifies the default event of the control.

As we type, the debounce setup waits for a second before applying model changes. However, in the case of blur, changes are reflected immediately.

Wondering why we require these options? Well, there are indeed some use cases where these options help. Assume we want to remotely validate if a username entered by a user exists. In a standard setup, every keypress would result in a remote call for validating a name. Instead, if we do a model update on blur, only one remote call would suffice. Type ahead input too can utilize these options (especially the debounce option) to reduce the number of remote requests.

The ng-model-options directive has some other interesting options that we will not be covering here. Look at the platform documentation at https://docs.angularjs.org/api/ng/directive/ngModelOptions to learn more about them.

So far, we have looked at ng-model from the data binding perspective, but ng-model has some other uses too.

The ng-model directive in itself is a mini MVC component that has its own controller. Through this controller, it exposes an API to format and validate model data.

Let's try to understand what happens when we create a form and add an input with ng-model. Consider this screenshot that is based on workout.html form layout:

As we can see from the preceding screenshot, when Angular encounters the form tag, it executes the form directive. This directive creates an instance of a special Angular class FormController that is made available to us on the current scope. See the previous screenshot. $scope.formWorkout is a FormController object and its name derives from a form name (name="formWorkout"). The form controller (the FormController object) provides an API to check and manipulate the state of the form.

On similar lines, when AngularJS encounters the ng-model directives, it creates a model controller (an instance of the ngModelController class). If the element with ng-model is defined inside a named form, the model controller instance is available as a property of the form controller (see $scope.formWorkout.workoutName in the screenshot).

Similar to FormController, NgModelController too provides an API to manipulate the model data. The next few sections cover the form, the model directives, and their respective controllers in more detail.

One question that we may have is, "Why do we need to know about form, ng-model directives?" Or do we really need to learn about FormController and NgModelController in detail? These are valid questions that we should address before getting into specifics.

We need to know about the form and ng-model directives from the usage perspective.

The FormController class is a useful utility class to manage the HTML form state.

NgModelController is commonly used to check the validation state of the input element. It is desirable to understand the inner working of a model controller as the complete validation framework, data parsing, and formatting are dependent on the NgModelController implementation.

Once we have a clear understanding of how these controllers work, life becomes a little easier when dealing with Angular form quirks.

NgModelController is the command center for the ng-model directive. It provides an API to:

To support formatting, parsing, and data validation, AngularJS implements a pipeline architecture (http://en.wikipedia.org/wiki/Pipeline_%28software%29). In a pipeline setup, data/control passes from one component to another in a linear fashion. There is uniformity of interface when it comes to the components that are part of a pipeline. The output from one component feeds into the next component in pipeline, so on and so forth.

AngularJS model controller defines two pipelines:

The following screenshot helps us visualize the formatter and parser pipelines in the context of model and view:

Having such a complex architecture for such a simple concept of model-view synchronization seems to be an overkill, but that is not the case. In fact, the pipeline architecture provides enough flexibility and extensibility. The complete AngularJS validation infrastructure is built upon formatter and parser pipelines.

As the name suggests, these pipelines make formatting a model and parsing view data easier. For example, if we want to format model data as uppercase in the input textbox, we can simply define the following formatter (code courtesy: API docs https://code.angularjs.org/1.3.3/docs/api/ng/type/ngModel.NgModelController):

function upperCase(value) {
   if (value) { return value.toUpperCase();}
}
ngModel.$formatters.push(upperCase);

An important consequence of using pipeline architecture with ng-model is that the order in which the pipeline functions are registered affects the overall behavior of the pipeline and hence ng-model. This holds true for both formatter and parser pipelines. Any pipeline function can short-circuit (clear) or update the value it receives during its execution, affecting the behavior of subsequent pipeline functions.

To understand the parser and formatter pipeline better, let's implement a sample formatter and parser function that can convert a decimal value to an integer value for our restBetweenExercise input textbox.

The rest between exercise input takes the rest duration (in seconds) between two exercises. Therefore, it does not make sense to save a decimal value for such input. Let's create a formatter and parser to sanitize the user input and model data.

Our formatter and parser functions work on similar lines, both converting the input value into integer format. Add the following watch function to WorkoutDetailController:

var restWatch = $scope.$watch('formWorkout.restBetweenExercise', 
  function (newValue) {
if (newValue) {
      newValue.$parsers.unshift(function (value) {
         return isNaN(parseInt(value)) ? value : parseInt(value);
      });
      newValue.$formatters.push(function (value) {
         return isNaN(parseInt(value)) ? value : parseInt(value);
      });
      restWatch(); //De-register the watch after first time.
    }
});

We register our formatter and parser once the restBetweenExercise model controller is created. The watch has been registered just to know when the model controller instance is created.

The expression inside the parser/formatter function is as follows:

return isNaN(parseInt(value)) ? value : parseInt(value);

It checks for the result of parseInt; if it is NaN (not a number), then it returns the value as it is, otherwise it returns the parsed value. Observe that we are not clearing the value if it is not a number, instead we are returning it as it is. Other formatters/parsers in the pipeline can take care of non-numeric values.

Also, we register our parser at the start of the parser pipeline by calling unshift and formatter at the end of the pipeline by calling push.

We can now test it out. Add the model data interpolation next to the Rest Time label:

Rest Time (in seconds):{{workout.restBetweenExercise}}

Load the workout builder page, enter a numeric non-integer value, and check the interpolation. It contains the integer part only. See the following screenshot:

This is our parser in action! To test the formatter, we need to provide a model property with a decimal value. We can set the model value in the controller init function where we assign the selected workout, something like this:

$scope.workout.restBetweenExercise = 25.53;

Load the workout builder page and we should see the following output:

This is our formatter in action!

We now have a fair understanding of formatter and parser pipeline, and have created a set of formatter/parser set too.

Formatters and parsers can be useful in a number of scenarios when dealing with user input. For example, we can implement a parser that takes the rest time input in hh:mm:ss format and converts it into seconds in the model. A formatter can be created to do the reverse.

It's time now to look at AngularJS validation infrastructure.

As the saying goes "never trust user input", and Angular has us covered here! It has a rich validation support that makes sure data is sanitized before submission.

In AngularJS, we have built-in support for validating input types including text, numbers, e-mails, URLs, radios, checkboxes, and a few others. Depending on the input type, we set the parameters (such as <intput type='email'). Correct validations are automatically setup by Angular.

Other than validations based on input type, there is also support for validation attributes including the standard required, min, max, and custom attributes such as ng-pattern, ng-minlength, and ng-maxlength.

Let's add the required validation to workout name (name="workoutName") input and see how it works. Update the workout name input to this:

<input type="text" name="workoutName" class="form-control" id="workout-name" placeholder="Enter workout name. Must be unique." ng-model="workout.name" required>

Now the input needs to have a value, else validation fails. However, how can we know if validation has failed? NgModelController comes to our rescue here. It can provide the validation state of the input. Let's add a message label after the input and verify this:

<label ng-show="formWorkout.workoutName.$error.required" ng-class="{'text-danger': formWorkout.workoutName.$error.required}"> 
  Workout name is required and it should be unique.</label>

Load the new workout page (#/buider/workouts/new) now and the error label appears as shown in the following screenshot:

Every model controller (such as formWorkout.workoutName shown previously) has a property $error that contains a list of all errors for the specific ng-model directive. The $error key (the property name) is the name of the validation (required in our case) that is failing and the value is true. If the key is not present on the $error object, it implies the input does not have the corresponding validation error. We use the $error.required error key to show the validation error and set an error class style.

Adding such a basic validation was easy, but there is a small issue here. The validation message is shown as soon as we load the form, not an ideal user experience. For a better user experience, the message should show up only after the user interacts with the input and not before that. AngularJS can help here too.

Every element that uses ng-model—including input, textarea, and select—has some states defined on the associated model controller:

$pristine$dirty or $touched$untouched is a useful property that can help us decide when error labels are shown. Change the ng-show directive expression for the preceding label to this:

ng-show="formWorkout.workoutName.$dirty && formWorkout.workoutName.$error.required"

Now reload the page, the error message is gone! Nonetheless, remember the control is still invalid.

As we can see, having a model state gives us great flexibility while managing the view, but the advantages don't end here. Based on the model state, Angular also adds some CSS classes to an input element. These include the following:

To verify it, just load the workout builder page and inspect the workoutName input element in the developer console:

<input type="text" name="workoutName" class=" form-control ng-pristine ng-untouched ng-invalid ng-invalid-required" ...>

Add some content to input and tab out. The CSS changes to this:

<input type="text" name="workoutName" class=" form-control ng-dirty ng-valid ng-valid-required ng-touched" ...>

These CSS class transitions are tremendously useful if we want to apply visual clues to the element depending on its state. For example, look at this snippet:

input.ng-invalid {  border:2px solid red; }

It draws a red border around any input control that has invalid data.

As we add more validations to Workout Builder, observe (in the developer console) how these classes are added and removed as the user interacts with the input element.

Now that we have an understanding of model states and how to use them, let's get back to our discussion on validations.

The workout data needs to be validated for a number of conditions. Let's get the complete set of validations from the workout.html file located in the workoutbuilder folder under Lesson03/checkpoint4/app/partials. Copy the inner content from <div id="workout-data" class="col-sm-3"> and replace the existing content inside the corresponding div element locally.

Also, comment out the formatter/parser watch that we created earlier to convert numeric data to integer values. We plan to do validations on the same field and those validations might interfere with the formatter/parser.

The workout.html view now has a number of new validations including, required, min, ng-pattern, ng-minlength, and ng-maxlength. Multiple validation error messages have also been associated with failing validations.

Let's test out one such validation (the restBetweenExercise model field) and understand some subtleties around AngularJS validations. Change the label Rest Time again to this:

Rest Time (in seconds): {{ workout.restBetweenExercise }}

Open the new workout builder page and enter some content in the input field of Rest Time. If we enter a numeric value, the model data updates immediately and gets reflected in the label, but, if we try to enter a negative value or non-numeric data, the model property is cleared. There are some important conclusions that we can derive from this behavior:

We can confirm the last finding too by setting the restBetweenExecise value to an invalid value. Update the init method set of WorkoutDetailController:

$scope.workout.restBetweenExercise = -33;

Now load a new workout builder view again. The value in the corresponding input is empty but the restBetweenExercise model has a value, as shown here:

To understand what happened, we need to understand how AngularJS does validation. This discussion however needs to be divided into two parts: one corresponding to pre-Angular 1.3 and the other to Angular 1.3.

Angular 1.3 differs a bit from its predecessors, hence this division. If you are still using pre-Angular 1.3, you can skip the section dedicated to validation in Angular 1.3.

How validation works (pre-Angular 1.3)

In AngularJS, validations are done using the parser/formatter pipelines. As detailed earlier, these pipelines are a series of functions called one after another and allowing us to format/parse data.

Angular too uses these pipelines to register validation functions within the pipeline. Whenever we use a specific input type (email, url, number), or we apply validation such as required, min, or max, Angular adds corresponding validation functions to the two pipelines.

These validation functions (inside the pipeline) test the input value against a condition and return undefined if the validation fails, otherwise, pass the value along to the next in the pipeline. The end effect is that model or view data is cleared on validation failures.

For example, have a look at the restBetweenExercise input:

<input type="number" ng-model="workout.restBetweenExercise" min="1" ng-pattern="/^-?d+$/" required ...>

Note

We could have implemented a positive integer value check by only applying ng-pattern="/^d+$/". Using two validators (min and ng-pattern) to achieve the same effect, allows us to showcase the different types of validations Angular supports.

It has checks for number, format, required, and minimum values. If we inspect the $formatters and $parsers pipeline for this input, a total of six formatters and five parsers are registered (a mere observation, not a documented fact). One of the validation functions that do regular expression-based validation (ng-pattern) is registered in both the formatter and parser pipelines and its implementation looks like this (from AngularJS source code 1.2.15):

function(value) {
  return validateRegex(pattern, value);
};

The validateRegex function returns undefined if the regex validation fails, hence clearing the value.

The following diagram depicts the behavior of the parser pipeline when data is invalid:

In the preceding screenshot, the first validation fails at the regex parser and the second at min value parser.

The formatter validation pipeline that maps model data to a view behaves in a similar manner to the parser pipeline. An important consequence of this behavior is that, if data in the model is invalid, it does not show up in the view and the view element is empty. Due to this, we cannot know the initial state of a model if the data is invalid and there is no validation error to guide us.

How validation works (Angular 1.3)

One of the major differences between pre-Angular 1.3 and 1.3 is that the validation functions of 1.3 are not part of parser/formatter pipelines. Validators in 1.3 are registered on the model controller property object $validators. Angular calls each function defined on the $validators property to validate the data.

Another difference is that validator functions in 1.3 return a Boolean value to signify if the validation passed or failed. In pre-Angular 1.3, the original value was returned if validation passed, and undefined when validation failed. To contrast the approach, look at the regex validator (ng-pattern) implementation in Angular 1.3.3:

function(value) {
        return ctrl.$isEmpty(value) || isUndefined(regexp) 
                             || regexp.test(value);
};

This function returns a Boolean result.

Due to the way validators are set up in Angular 1.3, there are some important implications:

• Formatters and parsers always run before validators get a chance to validate input. In pre-Angular 1.3, we could control the order.
• In the case of a parser pipeline (the one that converts a view value to a model) specifically, if there is failure during parsing, the validator pipeline is not called.
• In pre-Angular 1.3, a failed validator in the pipeline used to clear the input value, and the subsequent validators received undefined. In 1.3, each validator gets a chance to validate the input value irrespective of the outcome of other validations.

Look at the following diagram that highlights the data flow for Angular 1.3 validators:

Hope this discussion clears things up in terms of how validation in AngularJS works. Having this understanding is essential for us while we build bigger and more complex forms for our apps.

Angular 1.3 has another form of benefit. It can help us manage validation messages for failed validations more effectively. Angular 1.3 introduces two new directives: ng-messages and ng-message, to manage validation messages. Let's learn how these directives work.

<label ng-show="formWorkout.restBetweenExercise.$dirty && formWorkout.restBetweenExercise.$error.required" class="text-danger">Time duration is required.</label>

<div ng-messages="formWorkout.restBetweenExercise.$error"
ng-if="formWorkout.restBetweenExercise.$dirty">
    <label ng-message="required" class="text-danger">
Time duration is required.</label>
    <label ng-message="number" class="text-danger">
Time duration should be numeric.</label>
    <label ng-message="min" class="text-danger">
Only positive integer value allowed.</label>
    <label ng-message="pattern" class="text-danger">
Only integer value allowed.</label>
</div>

<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.3.3/angular-messages.js"></script>

angular.module('app', ['ngRoute', . . . , 'ngMessages']).

 { "required": true }

<label ng-message="required" class="text-danger">
  Time duration is required.</label>

{ "min": true, "pattern": true }

<div ng-messages=". . ." ng-messages-multiple>

A workout without any exercise is of no use. There should at least be one exercise in the workout and we should validate this restriction.

The problem with exercise count validation is that it is not something that the user inputs directly and the framework validates. Nonetheless, we still want a mechanism to validate the exercise count in a manner similar to other validations on this form.

Since Angular validations are built over ng-model, our custom solution too will depend on it. Add these lines inside the exercise list div element (id="exercise-list") at the very top:

<span name="exerciseCount" ng-model = "workout.exercises.length"> </span>
  <div class="alert alert-danger" ng-show = "formWorkout.exerciseCount.$dirty && formWorkout.exerciseCount.$error.count">
  The workout should have at least one exercise!
</div>

The previous span has an ng-model attribute pointing to exercise count. Quite interesting!

A standard HTML span does not support a name attribute. Add to that, the ng-model directive on span too makes no sense as the user is not directly manipulating the exercise count. Still, we have defined both the name and ng-model attribute on the span object.

Remember what we learned in the ng-model—beyond data binding section? When Angular encounters ng-model on an element inside a form, it creates an NgModelController object and exposes it on the scope using the name attribute (exerciseCount). The span setup is there to just get hold of the model controller so that the exercise count validator can be registered.

Let's see how to implement the custom validation logic. Add these two watches to WorkoutDetailController:

$scope.$watch('formWorkout.exerciseCount', function (newValue) {
     if (newValue) {
         newValue.$setValidity("count", 
           $scope.workout.exercises.length > 0);
     }});

$scope.$watch('workout.exercises.length', 
   function (newValue, oldValue) {
     if (newValue != oldValue) {
          $scope.formWorkout.exerciseCount.$dirty = true;
          $scope.formWorkout.$setDirty();
          $scope.formWorkout.exerciseCount
.$setValidity("count", newValue > 0); 
     }});

The first watch is on formWorkout.exerciseCount, an instance of NgModelController. This watch contains the initialization code for the exercise count validation. The watch is required because the WorkoutDetailController completes execution before the ng-model directive gets the chance to instantiate and attach the exerciseCount model controller to formWorkout. This watch gets fired once the model controller is available. We check for the number of exercises in the workout and set the validity of the model using the API method:

  newValue.$setValidity("count", 
    $scope.workout.exercises.length > 0);

The $setValidity function is used to set the validation key ("count") on the $error object for a failed validation. The second parameter signifies whether the validation defined by the key (the first parameter) is valid. A false value implies the validation has failed. The previous HTML uses formWorkout.exerciseCount.$error.count to show the error message accordingly.

Next, we need a mechanism to re-evaluate our validation logic when exercises are added or removed from the workout. The second watch takes care of this. Whenever the length of the exercises array changes, the watch is fired.

The watch implementation sets the form and the exerciseCount model controller, $dirty, as the exercises array has changed. Finally, the watch re-evaluates the count validation by calling $setValidity. If the workout has no exercise, the expression $scope.workout.exercises.length > 0 returns false, causing the count validation to fail.

Since we are implementing our own custom validation, we need to explicitly set the $dirty flag at both the form and element level. Form controllers have an API specifically for that $setDirty property, but in the model controller we just set the $dirty property directly.

Open the new workout builder page, add an exercise, and remove it; we should see the error The workout should have at least one exercise!.

What we did using custom validation could have been easily done by using an error label and ng-class without involving any of the model validation infrastructure. By hooking our custom validation into the existing validation infrastructure, we do derive some benefits. We can now determine errors with a specific model and errors with the overall form in a consistent and familiar manner.

To understand how model validation rolls up into form validation, we need to understand what form-level validation has to offer. However, even before that, we need to implement saving the workout, and call it from the workout form.

The workout that we are building needs to be persisted (in-memory only). The first thing that we need to do is extend the WorkoutService and WorkoutBuilderService objects.

WorkoutService needs two new methods: addWorkout and updateWorkout:

service.updateWorkout = function (workout) {
    var workoutIndex;
    for (var i = 0; i < workouts.length; i++) {
      if (workouts[i].name === workout.name) {
          workouts[i] = workout;
          break;
      }
}
    return workout;
};

service.addWorkout = function (workout) {
    if (workout.name) {
        workouts.push(workout);
        return workout;
    }
}

The addWorkouts object does a basic check on the workout name and then pushes the workout into the workout array. Since there is no backing store involved, if we refresh the page, the data is lost. We will fix this in the next Lesson where we persist the data to a server.

The updateWorkout object looks for a workout with the same name in the existing workouts array and if found, updates and replaces it.

We only add one save method to WorkoutBuilderService as we are tracking the context in which workout construction is going on:

service.save = function () {
  var workout = newWorkout ? 
    WorkoutService.addWorkout(buildingWorkout): 
      WorkoutService.updateWorkout(buildingWorkout);
   newWorkout = false;
   return workout;
};

The save method calls WorkoutService, addWorkout, or updateWorkout based on whether a new workout is being created or an existing one is being edited.

From a service perspective, that should be enough. Time to integrate the ability to save workouts into WorkoutDetailController and learn more about the form directive!

FormController plays a similar role for form HTML, as NgModelController plays for input elements. It provides useful functions and properties to manage the state of the form. We already have used some API functions and properties in the previous save method. The API includes the following functions:

Other than the state manipulation API, there are some handy properties that can be used to determine the state of the form. These include $pristine, $dirty, $valid, $invalid, and $error. Except for the $error property, the rest are similar to model controller properties.

We use the $dirty property with the workout title:

<h2 class="col-sm-5 col-sm-offset-1">{{workout.title}} {{formWorkout.$dirty?'*':''}} ...

It appends an asterisks (*) symbol after the title when the form is dirty.

We use the $invalid property of the form controller to verify if there are validation errors before we perform a save in WorkoutDetailController.

The $error property on the form controller is a bit more complex. It aggregates all failures across all contained inputs. The $error key (property name) corresponds to the failing error condition and the value is an array of controllers that are invalid. For a model controller, the value was just true or false. If we put a breakpoint on the $scope.save function on a new workout page, and click on Save, the $error object looks something like this:

The count error is for the custom validation we did for the exercise count. Three other validation errors are pertaining to empty inputs. Play around with the input elements and check how the formWorkout.$error object behaves. See how consistent it is with the individual model controller errors.

With this, we have covered most of the FormController API. The workout can now be saved, and later reopened for editing from workout the list page (#/builder/workouts).

Since forms are so commonplace in HTML development, there are some standard use cases and quirks that we encounter while using them with Angular. The next few sections talk about these quirks and use cases.

The first one is related to validation/error messages not shown when the form is submitted.

To observe the first quirk, open a new workout builder page and directly click on the Save button. Nothing is saved as the form is invalid, but validations on individual form input do not show up at all. It now becomes difficult to know what elements have caused validation failure. The reason behind this behavior is pretty obvious. If we look at the error message bindings for any input element, it looks like this:

ng-show="formWorkout.workoutName.$dirty && formWorkout.workoutName.$error.required"

Remember that earlier in the Lesson, we explicitly disabled showing validation messages till the user has touched the input control. The same issue has come back to bite us and we need to fix it now.

If we look at the model controller API, we do not have a function to mark the model dirty, in fact we have a method that is the other way around, $setPristine. Changing/manipulating the $dirty property directly is not desirable as this and similar properties such as $pristine, $valid, and $invalid are there to determine the state of the model controller and not to update its state.

Therefore, setting the $dirty flag is ruled out; instead we plan to employ a nifty trick. Let's introduce a new variable, submitted. This variable is set to true on the Save button click. Update the save implementation by adding the highlighted code:

$scope.save = function () {
    $scope.submitted = true; // Will force validations
    if ($scope.formWorkout.$invalid) return;
    $scope.workout = WorkoutBuilderService.save();
    $scope.formWorkout.$setPristine();
    $scope.submitted = false;
}

Nonetheless, how does this help? Well, there is another part to this fix that requires us to change the error message related to the ng-show expression. The expression now changes to:

ng-show="(submitted || formWorkout.workoutName.$dirty) && formWorkout.workoutName.$error.required"

With this fix, the error message is shown when the control is dirty or form Submit button is pressed (submitted is true). This expression fix now has to be applied to every ng-show directive where $dirty check is done.

Time to refactor the code as the expression has become a little complex. Add a hasError method in WorkoutDetailController:

$scope.hasError = function (modelController, error) {
  return (modelController.$dirty || $scope.submitted) && error;
}

The function does a similar check to the previous one in ng-show, but here we pass, in the controller, the error state parameter. The ng-show expression now becomes:

ng-show = "hasError(formWorkout.workoutName, formWorkout.workoutName.$error.required)"

Apply similar updates to all ng-show directives where $dirty is used.

If we now open the new workout builder page and click on the Save button, we should see all validation messages on the input controls:

Another common issue that we might encounter when we use AngularJS services and share data is unwanted model updates. To demonstrate this:

The changes have persisted! However, we did not save the workout.

Why did model changes persist in spite of not saving them? Any guesses? To give you a hint, the issue is not with the form or controller implementation, but the service implementation. Look at the getWorkout(name) function under sharedservices.js.

Time's up! Let's understand why. The getWorkout(name) implementation looks like this:

var result = null;
angular.forEach(service.getWorkouts(), function (workout) {
  if (workout.name === name) result = workout;
});
return result;

We iterate over the workout list and return the workout that matches the workout name. There lies the problem!

We return an element from the workout array (by calling service.getWorkouts()) and then bind it directly in the workout builder page. Due to this, any change to the workout in the workout builder affects the actual workout data. To fix the problem, we just need to return a copy of the workout instead of the original.

Update the getWorkout method implementation by changing the if condition to this:

if (workout.name === name) result = angular.copy(workout);

That's it! Go ahead and try updating the existing workout and navigate away. This time, changes are not persisted when we leave the page and come back.

Resetting the form to its initial state is another common requirement that we should add to our Workout Builder app.

The standard way of resetting the form is to call the reset method on the form object such as document.forms["formWorkout"].reset() or to use input type="reset", which clears all the form inputs. The drawback of this approach is that fields are completely cleared, instead of reverting back to their original content.

For Workout Builder, we will reset the form to its initial state using a similar approach outlined in the last section. Open workout.js, update WorkoutDetailController, and add the reset method:

$scope.reset = function () {
  $scope.workout = 
WorkoutBuilderService.startBuilding($routeParams.id);
  $scope.formWorkout.$setPristine();
  $scope.submitted = false;
};

We reset the workout object, set the form to pristine and the submitted variable to false for future validation. The startBuilding function internally calls the getWorkout method on WorkoutService. As we saw in the last section, getWorkout always returns a new copy of a workout, which finally gets assigned to $scope.workout as just mentioned, causing the form to reset to its original state.

However, what about the $routeParams reference given in the preceding code? $routeParams is an AngularJS service that complements the $route service and contains data about specific URL fragments. Since we have used it in save, why not formally introduce it and learn a bit more about it?

The $routeParams service contains route fragment values derived from the current route, for routes that are dynamic in nature. To understand it better, let's look at the route configuration for Workout Builder in the edit mode:

$routeProvider.when('/builder/workouts/:id', {

The previous route has a variable part :id that changes based on the name of the workout. For 7 Minute Workout, the route is this:

/builder/workout/7minuteworkout

The $routeParams service maps the literal string value 7minuteworkout to the id property and makes the data available to any controller/service (in this case, $routeParams.id).

In the case of a new workout, the route is /builder/workouts/new, and does not use any placeholder. Therefore, $routeParams.id is undefined in this case.

Coming back to the reset implementation, remember to add $routeParams dependency to the WorkoutDetailController declaration for the reset function to work correctly.

Finally, to bind the method to the form element, add a reset button to the form after the save button declaration:

<button class="btn btn-primary pull-right" ng-click="reset()">Reset</button>

We can now try it out. Create a new workout or open the existing one. Make some changes and click on Reset. The form should be reset to the state when it was loaded.

The reset is done, what next? We have still not implemented validation for the exercise duration of exercises that are dynamically added to the workout. Let's take care of this scenario too.

For dynamically generated form elements, as we have in the exercise list section, we still want to validate data entered by the user. AngularJS falls short in this scenario as the obvious validation mechanism does not work.

Ideally something like this should work for our exercise list in ng-repeat:

<input type="number" name="{{exercise.name}}-duration"  ng-model="exercise.duration"/>

Sadly, this does not work. AngularJS literally creates a model controller with the name {{exercise.name}}-duration. The reason is that the name attribute on the form and input (with ng-model) do not support interpolations. There is still an open issue on this (visit https://github.com/angular/angular.js/issues/1404 for more information).

The mechanism or workaround that Angular gives us to support dynamically generated inputs is the ng-form directive. This directive behaves in a similar manner to the form directive. It allows us to create nested forms and do individual form-level validation, with each form having its own set of inputs. Let's add ng-form and validate exercise duration.

<ng-form name="formDuration">
  <select class="select-duration form-control" name="duration" 
  ng-model="exercise.duration" ng-options="duration.value as duration.title for duration in durations" required>
    <option value="">Select Duration</option>
  </select>
  <label ng-show=
     "hasError(formDuration.duration,  
      formDuration.duration.$error.required)" 
      class="text-danger">Time duration is required.</label> 
</ng-form>