ITEC 325 2017fall ibarland

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

server-side-validation
Server-side validation

We will incrementally improve on hw03’s Okaymon page by adding server-side validation.
You may use parts/all of the hw03-soln and/or lecture example, as long as you cite it of course.

You should have a page https://php.radford.edu/~yourUserId/itec325/hw05/index.php which contains a link to: (i) this homework page, (ii) your okaymon-form.php, and (iii) your okaymon-handle-test-i.php files. (You're urged to automate this, similar-but-not-exactly-to this.) Be sure to use the filenames specified here. Presumably, you will want to start by copying your hw03/ directory to a new hw05/ (via cp -r …).

What to validate

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

1. The trainer's name is required and must contain at least one letter-character (not just digits/punctuation etc.), is at least 5 characters long, and no more than 50 characters long.
2. The species is required and must contain at least one letter-character (not just digits/punctuation etc.), and no more than 25 characters long¹.
3. The flavor-text is optional, but (if present) should be no more than 200 characters long.
4. The weight must be a non-negative number less than 10,000 (required).
5. All information from pull-down lists must be valid options (energy-types, weight-units) (required).
6. All information in radio-buttons must be valid options (required).
7. The Intellectual-Property waiver checkbox is required.
8. (bonus) 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.)

   warning:Only call trim on strings — not any sub-arrays inside $_POST! The function is_string can help.

code structure

1. (4pts) As before, after submitting okaymon-form.php 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 “field-name is either required or too long”, report “field-name is required”, or report “field-name is too long”.

2. (30pts for validation, including appropriate helper functions and their tests)
   Have a separate file okaymon-validate.php 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 of the form’s inputs, 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).
   • If a field can be validated with 1 line of code using standard php functions, you can do that instead of having a separate function for validating it.
   • 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.

   Each reported 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).

3. (3pts) Include an additional file “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..

   PHP tip: PHP, unlike most languages, has an …odd notion of “global variable”. Even if a function is defined in a context which had access to a variable, in order to use that variable inside the function you have to either look up its name inside the array $GLOBALS, or declare your intent by (re)declaring the variable as global inside your function.

   require_once("my-constants.php"); // defines variables `$foo` and `$bar`. echo $foo; function stuff() { echo $GLOBALS['foo']; // OR global $bar; echo $bar; }

4. (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.

Include unit-tests for each function you write, of course. Also, add at least two more “okaymon-handle-test-N.php” pages: one which has only a single invalid input, and one which has all inputs invalid (including the weight-units and energy-type). Keep in mind that if an input-field has multiple ways to be invalid, you should be confident your form-handler-tests catches the error — e.g. one where species which exceeds the max-length, and another where it has no letter-character.

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.

Any generic validation functions (which could be re-used directly for other projects) can be put into your utils.php. …Although, that name “utils” is starting to get a bit abused, since these aren't so much general-purpose utility functions, as part of a suite of validation functions. (You are encouraged, but not required, to put such 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.

hint: When grading, some of the automated things I'll check: one file has includes “constant” in it’s name; two files have the word “constant….php” inside them; the word “puddle” only occurs once; one file ends in “.css”.

set numConstFile = `ls * | grep onst | wc -l` set numConstFileTarget = 1 set numFilesMentionConst = `grep --files-with-matches -- -constant * | wc -l` set numFilesMentionConstTarget = 2 set numFilesMentionPuddle = `grep --files-with-matches puddle * | grep -v -- -test | grep -v -- -handle | grep -v -- -sample | w c -l` set numFilesMentionPuddleTarget = 1 set numPuddles = `grep puddle * | grep -v -- -handle | grep -v -- -test | grep -v -- -sample | wc -l` set numPuddlesTarget = 1 set numCSSFiles = `ls * | grep .css\$ | wc -l` set numCSSFilesTarget = 1

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)

©2017, Ian Barland, Radford University Last modified 2017.Oct.24 (Tue)

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