ITEC 325 2020fall ibarland

home—lects—hws
D2L—zoom (snow day)

html input forms, and php

a sample/demo form.

2020-Feb-11: Before class, watch (just) the third video: html `input` tag and friends (23m16s); (including boolean attributes, label tags, and id vs name attributes. The video alludes to material we haven't quite discussed yet (forms send key/value pairs to a form handler, using the attribute name), but the video still make sense w/o those details, which we will cover in class on Tuesday.

Forms and form-handlers:
A form is an html page where users may enter information (e.g. their favorite color, and whether or not they feel happy). Then, “submitting the form” just means requesting some other URL, but including the users's information along with that request.

Slightly more detail: When a user clicks submit, the browser takes the URL specified in the form tag — we call that URL the “form-handler”. As it requests the form-handler, it includes the form’s info along with the request, as key/value pairs (e.g. "fave-color" => "orange" and "isHappy" => "a-yep"). The form-handler (which might be a php program) can use this information to craft a response (html). Here is a small example.

The main thing to note is how the key-value pairs are specified. the form has input tags, with an attribute “name”. That name is what is used as the key, in the key-value pair! The value might come from the user (in the case of a input type='text' tag), or might be taken from the tag's value attribute (in the case of the checkbox shown).

Of secondary interest is the form tag itself. It's important attribute is action: When submitting, the browser merely requests the URL specified by action, and it also bundles along the key/value pairs specified by the form's inputs. If method='post', then the key/value pairs are instead passed along inside the http header (as already demo’d); if the method='get', the key/value pairs are attached at the end of the URL (you can check out form0-get.php).

We've already discussed that when itec-php01.radford.edu gets a request for a URL ending in .php, it runs that file as a program (returning anything that program printed out). But right before it runs the program:

1. The server starts a php-process, in the OS.
2. In that process’s memory-space, the server creates an array named “$_POST” and populates it with any key/value pairs that were in the http request packet.
3. In that process’s memory-space, the server creates another array, named “$_GET”, and populates it with any key/value pairs at the end of the URL (following a “?” in the URL)
4. Finally, it runs the requests php program, starting from line 1. That's why our PHP program has a arrays $_POST and $_GET to work with.

• HTML tags for Input Fields
  • text fields,

    <input type='text' name='txt1' size='10' maxlength='8' id='txtone' />

  • Numeric fields:

    <input type='number' name='age' size='5' maxlength='3' min='21' max='30' value='25' id='age' />

  video: form0 checkboxes (array_key_exists, etc) (14m38s)
  
  
  video: html input tags (minor details): radio buttons, select tags; boolean attributes; label tags; id vs name attributes (23m16s)
  
  
  • check boxes

    <input type='checkbox' name='cb1' value='milk' checked='checked' />

    
    In HTML, “checked” is an example of a boolean attribute, which are a bit odd: rather than having an attribute-value of 'true' or 'false', instead the attribute is either not-present-at-all (false), or it's present-and-its-value-is-the-same-word-as-itself¹ (true). It can't have any other value. Odd.
  • radio buttons

    <input type='radio' name='age' value='over50' id='age-over50' /> <br/> <input type='radio' name='age' value='30to50' id='age-30to50' /> <br/> <input type='radio' name='age' value='under30' id='age-under30' /> <br/>

    
    
    
    
    The value corresponding to age will be set to one of the three values.
    (A second set of unrelated radio buttons would share a different name attribute.)
    

    exceedingly optional: How the original radio-buttons worked: What happens in an old radio, when you turn the dial — how does a tuner actually receive different frequencies?

    Well, in order to pick up a different frequency, you want an antenna of a different length. That's because when a radio wave pushes the electrons in a wire, it's like pushing somebody on a swingset: if you push somebody at the right interval they'll go higher; you're pushing them at the right "frequency" for that swing-length. But if you push them at the wrong interval (say, at 30% of their swing, then 60%, then 90%, then 120% = 20% of their way back down), they go nowhere (your work is interfering with itself, yielding little-to-no net effect). In a piece of wire, all the ambient radiowaves are simultaneously pushing electrons at different timings, but because the electrons bounce/reflect off the end of the wire, only one frequency gets useful results (and that frequency depends on the length of the wire).

    Okay, so we want tuning a radio dial to make the antenna longer or shorter. Hmm, that's hard to implement, physically. However, there is a clever way to change its effective length: we can change the wire's capacitance instead (how hard it is to push the electrons along the wire). A variable-capacitor can be made by having two sets of interleaving metal plates; the amount the plates overlap changes the capacitance. video snippet (13sec): A variable-capacitance tuner

    So: in old-timey radios, the tuning dial is connected (just behind the faceplate) to a belt which turns the wheel we see the man rotating-by-hand in the video. This changes the amount of overlap of the interleaved-plates, which changes the capacitance, which changes what frequency will successfully push the electrons in the antenna!

    That just leaves the radio-buttons, to explain: the buttons were hooked up to a gear which had a belt to the tuning-dial. When you pressed a button, the tuning-dial also got spun! (As you might guess, you had to press the button pretty hard, to cause the tuning-dial to spin.)

    …Nowadays of course, knowing this is kinda moot — the buttons and dial are all electronic, the car drives itself, and it will auto-detect your mood, look up a favorite Pandora station, and start streaming songs with tailored ads. All without you understanding variable capacitance.

  • textareas:

    <textarea name='comments' id='comments' rows='3' cols='30'> Initial Contents </textarea>

    Initial Contents
    Note that this isn't an input tag — text areas get their own tag type, “textarea”.

    (I'm not really sure why text areas are different from from checkboxes/radio-buttons/text-fields². It'd seem more sensible to either have a single tag input with attributes for every possible type of input-widget, or have each type of input-widget be its own stand-alone tag. But going half-and-half on the issue only confuses me.)

  • Select Boxes (drop-down)

    <select name='title' id='title'> <option value = 'mr'>Mr.</option> <option value = 'ms'>Ms.</option> <option value = 'mrs'>Mrs.</option> <option value = 'miss'>Miss</option> </select>

    Mr. Ms. Mrs. Miss

    Note that if you omit the value attribute, then the value will be the option’s body-text.
    If you want to have a first item like

  • Submit button:

    <input type='submit' value='Submit Data to Server' />

  • Reset button:

    <input type='reset' value='Clear Form' />

label tags

You can use a label tag, to connect some text (anywhere on page) with (sending focus to) a particular input: See the example form below. Either enclose the text and the input inside the same label, or use label's for attribute.

Gotcha: While <input name='aNodeName'/> uses the name attribute to pass information to the action/request, the html <label for='aNodeId'>… uses id to refer to the DOM node of the current tree. (This actually makes good sense, but takes a moment of thought.)

Topics coming up: form-handlers and how to test them; grouping multiple inputs into an array; POST vs GET; sanitizing form info (against html-injection).

takeaways

• Submitting a form is just requesting a new page, except the http packet includes the form-info.
• The server runs the requested php program, but first it takes any form-info from the http-packet and kindly places it into the array _POST, for the program's use.
• Back in the form's html, the name attribute is used as the array-key, and the value attribute is used as the corresponding value in the array.

---

naming conventions

• Best practice: when including a name attribute, let your finger-reflexes add the id with the same value (except for radio-buttons, where the same name is shared among multiple tags).

  It's not so much that you always need both name and id, but it's not uncommon, and you should really name them the same thing. (This page made them slightly different, just so you could see the difference, and understand which is used where).

• In your php, if you pull something from $_POST into a variable for convenience, name your variable the same as the name/index. Just for your sanity.
• In your php form, use array_key_exists (or similar) to make sure the input was provided (not left blank by the user).
• The file containing the web-form and the file containing the handler should be consistently named. For example, for entering customer-info, I suggest³ “customer-info-form.html” and “customer-info-handle.php”.

home—lects—hws
D2L—zoom (snow day)

This page licensed CC-BY 4.0 Ian Barland Page last generated

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