ITEC 325 2012spring ibarland

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

php-ch03
html input forms, and php
chapter 3

From PHP Visual Quickstart Guide by Larry Ullman
Originally based on notes by Jack Davis (jcdavis@radford.edu)

• HTML tags for Input Fields
  • check boxes

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

  • text fields,

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

  • radio buttons

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

    
    
    
    
    The variable "age" will be set to one of the three values.
    (A second set of unrelated radio buttons would share a different name attribute.)
    
  • textareas:

    <textarea name='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'> <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
  • Submit button:

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

  • Reset button:

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

• GET & POST methods

  Q: But how is information communicated from a web form (pure html) to a php program?
  A: When you click 'submit', the HTML makes a page-request to the page specified by the form's "action" attribute. (Presumably it's a php page.) The page-request incudes extra information about what html input fields had been selected, etc.. The server gets that request and invokes the php file as normal, but it also pre-initializes an array of values for the program — and it fills that array with the extra information contained in the page-request.

  • GET - form data is sent to the server appended to the server script URL
    In the server script, data is retrieved via the super global associative array $_GET.
  • POST - form data is embedded in the http request header
    Server script - $_POST
  When to use which?:
  • GET requests can be bookmarked;
  • GET requests can't be too long (not > 1000s of characters?; think text-submit boxes)
  • POST requests are more secure against casual looking over the shoulder (but still vulnerable to packet sniffing etc.)
  • When refreshing a page created via POST, browsers tend to respond: “Refreshing will cause the page to re-submit; do you really want to do this?”
  • Possible guideline (?): If the page is changing a database's contents, use POST.
  • Many people suggest using POST as default.
  • Explore: How does a newspaper handle it? nytimes. Discuss: When might you choose to use post/get vs. could just have a separate URL for each result, e.g. different xkcd strips.
• Form Example
  • Simple Form Example
    php-ch03-form-example-submit.php

Errors

You must both (i) tell php whether to display errors, and (ii) what level of errors to display (notices, warnings, errors, etc.).

Note that telling php to display errors by calling a function at the start of your program (ini_set) is not ideal — if your file has a syntax error, it won't even start executing, so the command to display errors will never get reached! (This approach is still helpful for run-time errors though.)

• Call ini_set and display_errors at the start of your program.

  <?php error_reporting(E_ALL | E_STRICT); // Tell php to report errors ini_set('display_errors', True); // Tell apache to include stderr w/ the html-output ini_set('display_startup_errors', True); // Pointless, for this file -- startup is already finished. ?>

  
  Drawback: if you have a syntax error, not even the first line of your program will be run, and so it won't reach the first line asking to display startup errors.
• Have a small 4-line file which turns on error-reporting, and then includes your real file:

  <?php error_reporting(E_ALL | E_STRICT); // Tell php to report errors ini_set('display_errors', True); // Tell apache to include stderr w/ the html-output ini_set('display_startup_errors', True); // Useful for any *later* include'd files include('someFile-for-real.php'); ?>

  
  Drawback: You now have two files to manage, for every page (even if one is boilerplate).
• Set Apache's global configuration file, to display php errors.
  Drawback: On rucs, we can't change the global Apache configuration.
• The good solution that won't quite work for us:
  Set Apache's directory-specific .htaccess file to display php errors.

  # .htaccess -- a configuaration file which affects all files Apache serves # in its directory, as well as everything below that directory. # You might have this file in your personal root-php directory, # and other (cascading) such files in selected sub-directories. # Note: .htaccess on rucs.radford.edu does NOT allow setting php_value # (it will result in all pages generating a 500 error) # Turn on error-reporting: php_value display_errors True php_value display_startup_errors True # Note: for production you might want to configure to *log* errors instead of *display* # Note: you can also set this to "stderr" instead of "True" php_value error_reporting 32767 # Note: this should be whatever <?php echo E_ALL|E_STRICT;?> shows.

  
  Drawbacks:
  • While rucs' Apache install does respect .htaccess in general, it doesn't allow setting any php_value.² Attempting to do so results in Apache serving 500 errors for all pages anywhere in that directory.
  • It's Apache-specific (although several other web servers also respect files named .htaccess, so maybe it's a de facto standard).
  • The magic number 32767 is annoying (even if it's not platform specific and guaranteed not to change in the future — neither of which I'm entirely convinced about).
• A 99% solution: When debugging, always run php from the command line, before even running it via the web. Then, call ini_set and display_errors at the start of each php file, as mentioned previously. Include ini_setting startup errors, in case other files are included:

  <?php error_reporting(E_ALL | E_STRICT); ini_set('display_errors', True); ini_set('display_startup_errors', True); // in case we include other files ?>

• PHP Error Types

  Notice

  Non-fatal error that may or may not be indicative of a problem.
  E.g., Referring to a variable that has no value.

  Warning

  Nonfatal error that is most likely problematic.
  E.g., Misusing a function.

  Parse error

  Fatal error caused by a syntactic mistake.
  E.g., Omission of a semicolon or an imbalance of quotation marks, braces, or parentheses.

  Error

  A general fatal error.
  E.g., out of memory.

• Error Reporting Constants
  • E_NOTICE
  • E_WARNING
  • E_PARSE
  • E_ERROR
  • E_ALL
  • E_STRICT (the only one not already included by E_ALL; warns of things which might not be future compatible, etc.)

  As we saw, we can combine values (to use as an argument to error_reporting( $level )) by bitwise-ORing (“|”) various constants. legal error flags; It is recommended to use error_reporting(E_ALL|E_STRICT). (In 5.4.0, E_ALL finally includes E_STRICT; also notice that passing in ~0 (bitwise-negation of 0) will always set all values, even as new flags are added (up to 16 more new flags, at least).)

  See also various error functions.

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

©2012, Ian Barland, Radford University Last modified 2012.May.31 (Thu)

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