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

lect26-sticky
sticky forms

Sticky forms

A “sticky” form is one where, when you re-visit the form, your previous information is already filled in. In particular, we'll think of the scenario where somebody submits a form to the server, but the server rejects it — perhaps due to server-side validation, but it could also be because of session-timed-out, or item-out-of-stock ¹ or offer-has-expired, or whatever.

The html for an input form with a pre-filled value is easy: You just include the attribute value for text fields, and selected/checked for other elements:

      <label>First name: <input type='text' name='fname' value='Herman' /></label>
      <label>age: <input type='radio' name='age' value='over50' checked='checked'/></label>
      <select>
        <option>Option 1</option>
        <option selected='selected'>Option 2</option>
      </select>

First name: age:

But to do all this, the page that makes the form has to be the same as the page that receives the form! Example: lect26-sticky-form.php

BUT: if we submit to ourselves, we need to distinguish between two cases:

user came to this page via submitting (so we should complain about empty fields)
user came to this page for the very first time (so DON'T don't complain about empty fields)

             if (the form was submitted)
                 collect all error messages
                 }
             else {
                 (no error messages)
                 }
                 
           
             if (form-was-submitted && !$allErrorMsgs) {
                 ...handle the accepted form stuff...
                 }
             else {
                 ...print error messages, if any....
                 ...print the form, stickly:
                 echo "<input type='text' name='lastName' value='???' />
             }

(c1) How can we tell if this form was submitted vs a first-time visit?
(c2) for the last two branches -- can we keep our file/function from getting too long?

The answer for c1: Add a name/value to the submit button itself: <input type="submit" name='form-was-submitted' value='blah-blah-this-value-does-not-matter'/>
The answer for c2: require other files (existing from previous hws!).

(d) The result:

             // A new top-level file, "form-wrapper.php"

             if (array_key_exists('form-was-submitted', $_POST)
                 $errMsgs = validateAll(); //collect all error messages
                 }
             else {
                 $errMsgs = array();  // No errors -- first-time-visit.
                 }
                 

             if (array_key_exists('form-was-submitted', $_POST) && !$errMsgs) {
                 require('form-handle.php');  // Successful submit!
                 }
             else {
                 require('form.php');
                 // This file is our previous form updated so as to:
                 // - print all contents of $errMsgs (per hw05),
                 // - be sticky
                 // - submit to "form-wrapper.php" rather than "form.php"
                 }

Note that as a sticky-form, we are submitting to ourselves (although that's kinda obscured by the requires). I named this new one "form-wrapper.php", which requires either form-handle.php or form.php, but that's partly to preserve names with our previous arrangement. In practice, I'd probably name these files along the lines of form.php, form-handle.php, and form-print.php.

Looking forward: Sometimes a sticky-form's info comes from an initial attempt to fill it in. But sometimes you get a partially-filled form because the existing-info comes from a database instead of $_POST. In either case, form.php needs to do the same work, except that the info might not be coming from $_POST. One solution: Have both form.php and form-handle.php actually grab their information from some other global-array ², say “$formInfo”. Then, if somebody is editing data pulled from a database, the database-pulling-code simply loads its information into this variable $formInfo, and the exact same form.php now works for that!

¹ Of course, hopefully when an item is out of stock, the server might check that before having customers fill out the order form — perhaps before even showing the product page at all. It's more server load to do this, but much better user-friendliness. You can find a compromise by having a "check availablity" button, or checking availability when they put it into their cart, etc.. ↩

² It's poor practice to use globals like this; we'd rather pass parameters. So our form.php could define one huge function function printForm($formInfo) { ... }, and our wrapper could just call it. However: in php, you'd end up doing this having the function-body sometimes escaping out of php code (even though you're still inside a function-definition), which also feels really gross. Ideally, php would have allowed arbitrary nesting of entering sub-blocks which are php or plaintext, similar to (say) racket's “scribble” syntax: it nests better, and generalizes better. ↩

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

©2015, Ian Barland, Radford University
Last modified 2015.Nov.03 (Tue) Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu

lect26-sticky sticky forms

Sticky forms

lect26-sticky
sticky forms