ITEC 325 2016fall ibarland

home—lects—hws
D2L—breeze (snow day)

js-validation
Client side validation

Due: 2016.Oct.28 (Fri) 11:00. Submit on D2L, and as usual have your a link to your form available at https://php.radford.edu/~yourUserId/itec325/hw05/index.php. (No hardcopy needed.)

We will further improve on server-side-validation—Server-side validation's Okaymon page by adding client-side validation. Make a copy of your directory from hw04, named hw05/. (cp -pR hw04/ hw05 will Recursively copy directories, preserving timestamps.)

1. (5pts) As a warm-up: Make your submit-button be greyed-out (set its disabled attribute), if the Intellectual Property checkbox is not selected.

2. To report client-side verification errors: If you have a field (say, “passwd”), then you will use that same name in several ways:

   1. “passwd” will be the name attribute used in your HTML input tag (and hence the name of the value in the $_POST array);
   2. it will also be the id of the input tag, in the DOM;
   3. There will (optionally) be a paragraph with the id “passwd-err” — this will be where client-side validation error messages will be dynamically inserted into the DOM.

   Then, you will have a javascript function reportError which simply reports an (already-discovered) error-message, within the web page. When (say) reportError("passwd","the password is required"), is called, the function will

   1. (Extra credit:) Check if a node passwd-err already exists. If not, then create one: dynamically create a p (or, div, or span) node, and insert that node into the DOM immediately next to (as a sibling of) the passwd tag. This new node should have a css class “error-msg” or so.

      Remember:In HTML you specify a CSS-class using the attribute “class”, but in javascript/DOM that's a reserved word and you instead want to set the DOM attribute “className”.)

      If you don't want to do this extra credit, then instead include p tags with names like passwd-err manually; these tags will otherwise be empty, initially.

   2. (15pts) In the (say) “passwd-err” node, it will assign to the innerHTML or innerText property. (Your function should append to any existing text, rather than just overwrite any existing innerText, so that multiple validation functions can all inform the user about any errors without overwriting each others’ messages.)
   3. From the notes, you'll want to recall the following functions in particular: getElementById, createElement, createTextNode, setAttribute, insertBefore. Here's a working example:

      var somePara = document.getElementById("my-favorite-para"); somePara.style.color = "blue"; somePara.innerHTML += "<em>watch out</em> &mdash; we're at the end.";

      Show-source, to see how the following buttons are implemented.
      
      Be sure to use a javascript console plug-in — Chrome » View » Developer » Javascript Console » Elements — to get feedback on undefined (misspelled) functions etc..
   4. (5pts) Finally, you will want a function which clears all the text from an …-err node; presumably this gets called when the field succesfully validates, and when you start a top-level page validation (since that's when you'd want to clear out any old errors).

3. (30pts) For each input field, have a javascript function which validates it: (a) returns true if the field is validated, and (b) otherwise returns false and displays an error message by calling reportError above. This function should be the callback for that input's onchange event (or, onblur).

   Use the same validation criteria as we did in hw04.

   Note: Unfortunately, Javascript regexps do not yet support the unicode properties. So you can use /[A-Za-z]/ to detect letters.

   It is not strictly necessary that your javascript verify (say) that the drop-down contains one of the menu items, since your HTML input already enforces that. Likewise, it's not strictly necessary for the validation-function to verify that the maximum-lengths are enforced, if your HTML input tags already had a maxlength attribute.

   However, one advantage to still include these checks: If we have to repeat the validation code in two different places (in two different languages), then it's nice if those two copies of the code can be as similar as possible, more of a rote translation than requiring thought about what parts of the code can be elided from one version but are essential for the other.

   Note: If the max-length is included in both the form and the php-validation, then you only want to mention it once! Add the max-lengths to your php-constants file, and have the form's php print the constants when generating (printing) the html-form.

   Extra credit (5pts): Unit tests are not required for your javascript functions. However, if you are interested in doing some unit test for your javascript, see www.smashingmagazine.com/2012/06/27/introduction-to-javascript-unit-testing/.

4. (5pts) Then, have an overall function validateAll() which just calls all the others, and &&’s the results. (Be sure to validate all the fields, even if the first one fails.)

   If your form does not validate, it should not submit.

5. Optional/extra-credit: For text inputs, immediately upon being entered, your javascript can trim and collapse whitespace as in hw02. (And for even a bit more extra-credit, if this results in changing what the user typed, you can display a message politely informing the user that their information was changed/normalized. You should be able to re-use code which inserted error-messages, perhaps refactoring a bit to support error- and non-error messages.)
6. (Optional — 0pts) Separate your general-purpose javascript and php functions into their own file (the functions that you would likely want to re-use in future homeworks, like the javascript function for adding error messages, and validating that a string is a numeral within a specified range).

Make your page look neat and professional!

Other requirements

• Each file start should start with with a PHP or HTML comment with your name, class, etc. (after a doctype declaration and perhaps <html>).
• Use meaningful variable names, function names, and good comments as needed.
• Write functions (both php and javascript) as appropriate, to avoid repeated work.
  I recommend writing functions that return strings rather than print (as convenient), and including one or two test-cases as examples. Writing the test-case first often clarifies exactly what your code needs to return.
• Use standard XHTML tags and make sure any javascript does not use browser-specific constructs.
• All code/html should be well formatted with appropriate white space and indentation so it is easy to read.
• Strive to minimize lines of code longer that 100 characters.
• If you have any questions, use the discussion board.
• Do not modify your final submission after the due-date; if you want to make changes, copy all your files to a new directory and work on those.

   /** Insert a node into the DOM after the referenceNode.
    * (Complements javascript's existing 'insertBefore'.)
    * @param (node) referenceNode -- the node after which the new node will be added.
    * @param (node) newNode -- the new DOM node to add.
    * @return void
    * @author lobo235, at http://www.netlobo.com/javascript-insertafter.html
    * @version 2007.Nov.07
    */
  function insertAfter( referenceNode, newNode ) {
    referenceNode.parentNode.insertBefore( newNode, referenceNode.nextSibling );
    }

home—lects—hws
D2L—breeze (snow day)

©2016, Ian Barland, Radford University Last modified 2016.Oct.21 (Fri)

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu