ITEC 325 2015spring ibarland

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

hw05
Server-side validation

Due: Part (a) 2015.Mar.06 (Fri) 11:00 on D2L only;
The full homework: Mar.16 (11:00), D2L and sources visible on php.radford.edu. (No hardcopy needed.)
For part (a):

• a demo-page which simply sumbits some egregiously incorrect inputs,
• The structure as described below: a function validateAll, 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.
• validateAll needs only to correctly validate any one input field, for part (a).

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

As in previous homeworks, your page at https://php.radford.edu/~yourUserId/itec325/hw05/index.php should have a link to your skill-entrytrivia-question form near the top, and include a list all your files (with links), and should also display their source (between Mar.♣17 and Jun.01). Presumably, you will want to copy your hw03 directory to a new hw05 (cp -r …).

Server-side validation

As before, after submitting the trivia-question-form will lead to a page printing the entered information. However, the page's title (and, its heading) should be something like “trivia-question submitted” (as before) or “trivia-question 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).

• The Hint and Weight are optional; the rest of the fields are required.
• The “Author username”, “Answer”, and “Hint” may not contain newlines, and should each contain at least one letter-character. (Again, use a unicode property.)
• The “Author username” 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 Question should contain at least one letter-character; it should have a max-length, but be generous.
• The weight (if given) 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 “category” attribute must have at least one box checked, and all selections must be from the allowed categories.
• The “subcategory” should only have a selection if the “science” category was selected.

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

Structure of code

• Include an additional file (perhaps named “tq-constants.php”) which simply defines things needed by both the form-generation and the form-validation: the list of categories, the minimum and maximum skill-levelweight, the max-length of all pertinent fields², etc..
• 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 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 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 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—exams—hws
D2L—breeze (snow day)

©2015, Ian Barland, Radford University Last modified 2015.Mar.04 (Wed)

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