anchor.diff:  .l-main-section
   a#template2
   :marked
  -  ## Template-Driven Forms with validation messages in code
  +  ## Template-driven forms with validation messages in code
   
     While the layout is straightforward, 
  -  there are obvious shortcomings with the way we handle validation messages:
  +  there are obvious shortcomings with the way it's handling validation messages:
   
     * It takes a lot of HTML to represent all possible error conditions. 
     This gets out of hand when there are many controls and many validation rules.
     
  -  * We're not fond of so much JavaScript logic in HTML.
  +  * There's a lot of JavaScript logic in the HTML.
   
     * The messages are static strings, hard-coded into the template. 
  -  We often require dynamic messages that we should shape in code.
  -
  -  We can move the logic and the messages into the component with a few changes to 
  +  It's easier to maintain _dynamic_ messages in the component class.
  +
  +  In this example, you can move the logic and the messages into the component with a few changes to 
     the template and component.
     
  -  Here's the hero name again, excerpted from the revised template ("Template 2"), next to the original version:
  +  Here's the hero name again, excerpted from the revised template 
  +  (Template 2), next to the original version:
   +makeTabs(
     `cb-form-validation/ts/src/app/template/hero-form-template2.component.html, 
      cb-form-validation/ts/src/app/template/hero-form-template1.component.html`,
  
positive.code: 
  a#top
  :marked
    We can improve overall data quality by validating user input for accuracy and completeness.
  
    In this cookbook we show how to validate user input in the UI and display useful validation messages 
    using first the template-driven forms and then the reactive forms approach.
  .l-sub-section
    :marked
      Learn more about these choices in the [Forms chapter.](../guide/forms.html)
  
  a#toc
  :marked
    ## Table of Contents
  
      [Simple Template-Driven Forms](#template1)
  
      [Template-Driven Forms with validation messages in code](#template2)
  
      [Reactive Forms with validation in code](#reactive)
  
      [Custom validation](#custom-validation)
  
      [Testing](#testing)
  
  a#live-example
  :marked
    **Try the live example to see and download the full cookbook source code**
  live-example(name="cb-form-validation" embedded img="cookbooks/form-validation/plunker.png")
  
  .l-main-section
  a#template1
  :marked
     ## Simple Template-Driven Forms
  
     In the template-driven approach, you arrange 
     [form elements](https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms_in_HTML) in the component's template.
  
     You add Angular form directives (mostly directives beginning `ng...`) to help
     Angular construct a corresponding internal control model that implements form functionality.
     We say that the control model is _implicit_ in the template.
  
     To validate user input, you add [HTML validation attributes](https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5/Constraint_validation) 
     to the elements. Angular interprets those as well, adding validator functions to the control model.
  
negative.code:    Angular exposes information about the state of the controls including 
     whether the user has "touched" the control or made changes and if the control values are valid.
  
     In this first template validation example, 
     notice the HTML that reads the control state and updates the display appropriately.
     Here's an excerpt from the template HTML for a single input control bound to the hero name:
  +makeExample('cb-form-validation/ts/src/app/template/hero-form-template1.component.html','name-with-error-msg','template/hero-form-template1.component.html (Hero name)')(format='.')
  
  :marked
    Note the following:
    - The `<input>` element carries the HTML validation attributes: `required`, `minlength`, and `maxlength`.
  
    - The `name` attribute of the input is set to `"name"` so Angular can track this input element and associate it
    with an Angular form control called `name` in its internal control model.
  
    - The `[(ngModel)]` directive allows two-way data binding between the input box to the `hero.name` property.
    
    - The template variable (`#name`) has the value `"ngModel"` (always `ngModel`).
    This gives you a reference to the Angular `NgModel` directive 
    associated with this control that you can use _in the template_
    to check for control states such as `valid` and `dirty`.
  
    - The `*ngIf` on the `<div>` element reveals a set of nested message `divs` but only if there are "name" errors and
    the control is either `dirty` or `touched`.
  
    - Each nested `<div>` can present a custom message for one of the possible validation errors.
    There are messages for `required`, `minlength`, and `maxlength`.
  
    The full template repeats this kind of layout for each data entry control on the form.
  a#why-check
  .l-sub-section
    :marked
      #### Why check _dirty_ and _touched_?
  
      The app shouldn't show errors for a new hero before the user has had a chance to edit the value.
      The checks for `dirty` and `touched` prevent premature display of errors.
  
      Learn about `dirty` and `touched` in the [Forms](../guide/forms.html) guide.
  :marked
    The component class manages the hero model used in the data binding
    as well as other code to support the view.
  