ITEC325 hw-sticky-ec -- Sticky form

hw-sticky-ec
Sticky form
extra-credit

Due: Dec.15 (Thu) 17:00 (!)
Submit on D2L, and have links to your form and form-handle-tests available at https://php.radford.edu/~yourUserId/itec325/hw-sticky-ec/index.php. (No hardcopy needed.) This homework is worth 25pts of extra-credit.

Sticky form

Modify your Okaymon form so that it is sticky: on validation error, you are given back the form, except that any information from $_POST is pre-filled into the form (even if it wasn't valid).

A sticky-form submits to itself, conceptually. However, we still like having the form-printing and the success-handling be in separate files. So create a new top-level page, including the other files as appropriate. (Recall the skeleton given in the lecture notes.)

The one other change that this structure will require is that your handle-sample tests will need to change the name of what file they require after initializing $_POST.

For full credit, be sure to have your drop-downs, radio buttons, and check-boxes sticky, too. Since some of these were generated by a function, this means modifying those functions so that they are passed in an extra argument indicating what element(s) are to be pre-selected. This new argument should be an optional parameter, so it is backwards-compatible with your existing test-cases.

For the radio-button table, this means passing in an array indicating what should be pre-selected for each row. You may want to refer to the posted hw-solution, where table's radio-button names were already such that the handler received them in a single array rather than a bunch of values mixed in with the form's other inputs.

As usual, test-cases are a significant portion of the points-possible. Writing your test-cases first saves you time, honest!

For further extra credit: Modify the form-printing so that instead of hard-coded to use $_POST, it is a function which takes in an array to use as the sticky-info. This work will pay off in the future, when we want to allow users to edit form-info that came from a database (instead of from a form inside $_POST).

In order to do this, you are reluctantly allowed to use php's ability to break if-else statements across different <?php …> blocks:

<?php if (someCondition()) {>
  <p>This paragraph is actually inside the
  if-branch, even though we're not inside php-mode!
  This is odd, <?php echo $_POST['name']>, no?
  </p>
<?php else { >
  <p>Hmmm.
  </p>
<?php } >

(This feature definitely smells bad to me, but there aren't good solutions.

If one of the branches was short (like the else branch above), embedding it in an explicit echo wouldn't be too bad (but slightly annoying).
And if it's very long, then embedding it in a separate, required'd file would be reasonable (though even more annoying).

But for something like our case (taking a reasonably-sized function, and converting it to echo-statements) is too painful.

The proper solution, btw, is obvious but not supported by php: php should let me nest non-php-modes inside php-mode—that would exactly capture the program's real structure, while preserving php's cool feature of implicit-printing.) For a system that does this correctly, see racket's “scribble” syntax.

Other requirements

(this list is unchanged from previous hw)

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.

¹ Admittedly, out checkbox for the IP-waiver is one that is often not made sticky on real forms, since you want to be sure people check it off based on *everything* they filled in, as opposed to the info they'd filled on their first attempt. However, as a proof-of-concept for this assignment, do make sure it's checked. ↩

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

hw-sticky-ec Sticky formextra-credit

Sticky form

Other requirements

hw-sticky-ec
Sticky form
extra-credit