ITEC 325 2016fall ibarland

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

server-side-validation
Server-side validation

Due: Part (a) 2016.Oct.17 (Mon) 23:59 on D2L only;
The full homework: Oct.19 (Wed) 11:00, D2L and forms available at php.radford.edu/~yourUserName/hw04/index.php. (No hardcopy needed.)
For part (a), include:

• a handle-demo-page which simply sumbits egregiously incorrect inputs for every single field (e.g. items that weren't in pulldown lists, and values that weren't from radio-buttons.) (If some fields have "different" ways in which they can fail validation — too long, or invalid characters — then you'll eventually want each such failure-mode to be tested in some handle-demo.
• The structure as described below: a function allErrorMessages, which returns an array of error message(s), and the form-handler which calls that function and then prints all resulting error-messages at the top of the form.
• allErrorMessages needs only to correctly validate any one input field, for part (a).

We will incrementally improve on hw03—hw03: form-handling: and html sanitizing's Okaymon page by adding server-side validation.

Your should have a page https://php.radford.edu/~yourUserId/itec325/hw04/index.php which contains a link to your okaymon form (and, to this homework) near the top, and include a list all your files (with links). (That is, a link to each of your handler-sample files, and a link to your css file, etc.. Hint: scandir.) Presumably, you will want to start by copying your hw03/ directory to a new hw04/ (cp -r …).

Server-side validation

(6pts) As before, after submitting the okaymon-form will lead to a page which prints the received information. However, the page's title (and, its headline) should be either something like “okaymon info submitted” (as before) or something like “okaymon form contained n errors”. Then, if there were errors, give a list of the error-messages before printing the received-information. Error message should be specific: e.g. rather than saying a field is “either required or too long”, just report the true problem.

What to validate

The following properties should hold (and you should report a validation-error-message if they don't):

• (3pts) The trainer is required and must at least one letter-character (not just digits/punctuation etc.), and no more than 50 characters long.
• (2pts) The species is required and must at least one letter-character (not just digits/punctuation etc.), and no more than 25 characters long.
• (2pts) The flavor-text is optional, but (if present) should be no more than 200 characters long.
• (2pts) The weight must be a non-negative number less than 10,000.
• (6pts) All information from pull-down lists must be valid options (energy-types, weight-units).
• (2pts) The Intellectual-Property waiver checkbox is required.
• (2pts) In validating the above properties, first trim any leading/trailing whitespace from the user’s input. (You don't need to trim from values in pulldowns/checkboxes.)

Include unit-tests for each function you write, of course. Also, add at least two more “form-sample” pages: one which has only one invalid input, and one which has all inputs invalid (including the weight-units and energy-type).

You might want to start by creating another sample-page which includes some of the wacky things to check for: an entry which is nothing but spaces; an entry claiming the that the dropdown-item “easy-peasey-lemon-squeezy” was selected (even though your dropdown has no such option), etc.. This will help focus your thoughts about what you need to check, when validating.

Structure of code

• (4pts) Include an additional file (perhaps named “okaymon-constants.php”) which simply defines things needed by both the form-generation and the form-validation: the list of categories, the maximum weight, the max-length of all pertinent fields, etc..
• (4pts) 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 hw03 screenshot form shows 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 weight restriction and the page's signature at the bottom.
• (5pts) Have a separate file that contains validation-functions specific to this form. Include a top-level function allErrorMessages 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 weight, 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['weight'],50,100,'weight')

  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 allErrorMessages, it's acceptable just to check whether the array it returns has the intended number of items: test( count(allErrorMessages( 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 sample-i files.

• (5pts) When checking that the radio-buttons (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)

©2016, Ian Barland, Radford University Last modified 2016.Oct.12 (Wed)

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