RU beehive logo ITEC dept promo banner
ITEC 325

D2Lbreeze (snow day)

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>
        <option>Option 1</option>
        <option selected='selected'>Option 2</option>

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

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

(c) Imagine a big if-statement:

             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 = allErrMsgs($_POST); //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 {
                 // This file is our previous form updated so as to:
                 // - print all contents of $errMsgs (per hw05),
                 // - be sticky    [hint: have a helper `lookup($arr,$idx,$dflt)`]
                 // - 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!

1 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..      

2 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.      

D2Lbreeze (snow day)

©2016, Ian Barland, Radford University
Last modified 2016.Oct.14 (Fri)
Please mail any suggestions
(incl. typos, broken links)
Rendered by Racket.