home—lects—hws
D2L—breeze (snow day)
server-side-validation
Server-side validation
Due: Part (a) 2017.Mar.03 (Fri) 23:59 on D2L only;
The full homework: Mar.14 (Tue) at class time16 14:00 (Thu)
Submit files on D2L,
and have them online at php.radford.edu/~yourUserName/hw05/index.php.
(No hardcopy needed.)
For part (a), include:
-
One okaymon-handle-test-N.php 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.
-
The structure as described below,
for the file okaymon-validate.php:
a function allErrorMessages as described,
and the form-handler which calls that function
and then prints all resulting error-messages at the top of the form.
-
For part (a), the function allErrorMessages needs only to
correctly validate any one input field.
We will incrementally improve on hw03—hw03: form-handling: and html sanitizing's Okaymon page by
adding server-side validation.
(You may use parts of the hw03 solution, 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.
Be sure to use the names specified here.
Presumably, you will want to start by copying your hw03/ directory
to a new hw05/ (via cp -r …).
Server-side validation
(6pts)
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 “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'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.
- (2pts) The species is required and must contain 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).
- (6pts) All information in radio-buttons must be valid options.
- (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.)
warning:Only call trim on strings — not any
sub-arrays inside $_POST!
The function is_string can help.
(6pts)
You must have a function allErrorMessages which (as we'll discuss in class)
takes an array of form-info, and returns an array of error-messages.
Your test-cases for this might simply test that the returned array has the expected number
of messages, w/o checking the exact text of the messages.
Have helper functions for general-purpose/re-usable tasks, as appropriate (e.g. a function
rangeErrorMessage : string, number, number → string-or-false
which makes sure an input is a number in the expected range (returning an error-message if
it's not, or just false if it is in the range).
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 catches the error
— e.g. a species which exceeds the max-length, and another with 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.
Structure of code
-
(4pts) 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 declare your intent by declaring the variable as
global.
- (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 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 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).
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.
-
(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
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.
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)
radford.edu