ITEC 325 2014fall ibarland

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

hw04
Server-side validation

Due: 2014.Oct.18 (Sat) 23:59

We will incrementally improve on hw03—sanitized html: and automated source-listings's .W.o.W. page by adding server-side validation.

As in previous homeworks, your page at https://php.radford.edu/~yourUserId/itec325/hw034/index.php should have a link to your skill-entry form near the top, and include a list all your files (with links), and should also display their source (between Oct.20 and Dec.22). See hw03-soln/ for an example. Presumably, you will want to copy your hw03 directory to a new hw04 (cp -r …).

Server-side validation

As before, after submitting the skill-form will lead to a page printing the entered information. However, the page's title (and, its heading) should be something like “skill submitted” (as before) or “Skill form contained n errors”, as appropriate. Then, if there were errors, give a list of the error-messages, before printing the entered information as before. (In particular, we are not (yet) sending them back to the form, on a failed-submit; that's next hw.)

What to validate

When considering any text input, trim leading/trailing whitespace, and collapse multiple (interior) horizontal-space into a single space-character. (Use the unicode property \p{Z} and preg_replace.) After that, the following properties should hold (and you should report a validation-error-message if they don't):

• All text should be non-empty.
• the skillname and “your name” may not contain newlines, and should each contain at least one letter-character. (Again, use a unicode property.)
• The skill-description should contain at least one letter-character; it should have a max-length should exist but be generous.
• The “Your name” field must be allowed to be long enough that somebody named Kimberleigh-Annabelle Josephine Montgomery-O’Richardson ¹ won't be offended, but can't allow input that is too long> (We want to guard against somebody who inadvertently pastes in some other long text into that input.)
• The level must be a number in the indicated range.

  Hint:Use numeric operators like < to compare numbers — not regular expressions. Also, see is_numeric.

  (Design choice: do you want to allow people to type things like "0099"? If the range had happened to include 0, would your verification accept "-0"? Should it?)

  As part of this step, you must have a function that takes in a string (the characters typed in the form) and two integers (an upper and lower bound), and returns an error message (if it doesn't represent an integer in that range, inclusive), or the empty string (if it does). Be sure to give a descriptive name to this function.

• The “tied to” attribute must be one of the menu-items listed.
• The “available-to” needs at least one item selected, and every selection must be one of the classes listed.

Structure of code

• Include an additional file (perhaps named “wow-constants.php”) which simply defines things needed by both the form-generation and the form-validation: the list of possible attributes, the minimum and maximum skill-levels, and the max-length of all pertinent fields². Make sure your form's text inputs hew to these maximum-lengths.
• Include an external CSS file. Include at least two named styles; think up appropriate names³ for them:
  • A class for important information, that centers its text and otherwise draws attention to it. Use this for the page's title (which might further be in an h1 heading-tag). For example, the example form draws a green box around important items.
  • a class that has font-size: smaller and font-style: italic. Use this for both the form's reminder information about the restriction on min-level, and the page's signature at the bottom.
• Have a separate file that contains validation-functions specific to this form. Include a top-level function validateAll which takes in an array containing what $_POST might contain, and return an array of 0 or more error-messages. For each input, have either:
  • a function specifically for validating that field, which either returns an error-string, or false;
  • a single-line generic validation-function you can call, and using its result construct an error message (if applicable).

  Each individual validation-error message should start with the name of the field containing the error (probably name attribute itself, so long as that name is human-understandable).

  You are encouraged (but not required) to put any generic validation functions into a separate file yet. The rule-of-thumb would be: Might this be code you'd want to repeat when validating an entirely different web-form (like your project)? No matter how you organize your code, each file of functions should have its own associated -test file.

  For example, for validating the min-level, have a generic function that compares an input-string against any two numbers. In order to be able to return a helpful error message, that function might also take in the field's name, perhaps numInRangeErrMsg($inputs['minLevel'],30,100,'minimum skill level')

  You can test your top-level

  For functions returning false-or-error-string, it's acceptable to just test whether the result is false (w/o worrying about the exact error-message contents). For testing validateAll, it's acceptable just to check whether the array it returns has the intended number of items: test( count(validateAll( array(…)), 3 );. Be sure to test for each of the validation-tasks listed above! You might keep your test-arrays aligned with the same arrays used in your *_demo files.

• When checking that the drop-downs (or, check-boxes) are valid, do not use a six-way if-else-if; use in_array, along with the arrays defined in your common-constants file.

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.
  Include test cases for all non-void functions. The number of test cases depends on the particular function; include enough to capture different sorts of answers.
  (For example, pluralize deserves at least three tests: the numbers 0, 1, and more-than-one; blend deserves at least four tests: each of the two input strings could be odd or even, and that affected the splitting-point; wanted strings of even-length and odd-length; a function to create a drop-down html menu might be fine with just one test case (an array with several items) if you are confident that an empty-array or array-with-one-element is not really any different behavior.)
  Remember, writing test-cases 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.

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

©2014, Ian Barland, Radford University Last modified 2014.Oct.14 (Tue)

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