Due: 2016.Mar.23 (Wed) 16: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.)
(5pts)
As a warm-up:
Make your submit-button be greyed-out (set its disabled attribute),
if the Intellectual Property checkbox is not selected.
To report client-side verification errors:
If you have a field (say, “passwd”), then
you will use that same name in several ways:
“passwd”
will be the name attribute used in your HTML input tag
(and hence the name of the value in the $_POST array);
it will also be the id of the input tag, in the DOM;
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
(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 use the attribute named “class”, but
in javascript/DOM that's a reserved word, and you want to set the DOM attribute named “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.
(15pts)
In the (say) “passwd-err” node,
it will assign to the innerHTML or innerText property1.
(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.)
From the notes,
you'll want to recall the following functions in particular:
getElementById,
createElement,
createTextNode,
setAttribute,
insertBefore2.
Here's a working example:
var somePara = document.getElementById("my-favorite-para");
somePara.style.color = "blue";
somePara.innerHTML += "<em>watch out</em> — 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..
(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).
(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.
(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 fails3.)
If your form does not validate, it should not submit.
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.)
(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
These apply to all homeworks for this class:
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 convenient4),
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.
1
Note that setting innerText sanitizes any html-characters,
while setting innerHTML lets you insert actual HTML mark-up
(if, say, one particular word of the message were to be <em>phasized).
If the error message only incorporates user-info from what the user just provided,
then perhaps sanitizing isn't critical in this case.
However, when using sticky-forms, we might use data that came from a database, which
could happen to have HTML-meaningful characters, and which might weasel their way into error messages.
So if not otherwise needed, innerText is recommended.
Of course, setting DOM attributes (esp. className, for the class
attribute)
for the node is how might format the overall node.
↩
2
There is, oddly, no standard js/DOM function “insertAfter”,
just “insertBefore”.
You might find this simple helper function helpful:
/** 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 );
}
3In this case,
short-circuiting is not what we want. This stems from the fact that our
validation-functions not just returning a value; they are having
the side-effect of displaying the error. Many (including me) would argue
it's poor practice to have a function which both returns and has a
side-effect, but I'll make an exception for functions which are so
intrinsically tied to I/O, the ultimate side-effect. ↩
4the function to show-source a file is one of the few exceptions ↩
radford.edu