ITEC 325 2014fall ibarland

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

lect05-xhtml
xhtml
and: error-reporting; default-print

• Running your php programs:
  1. First run them directly from the command-line: php myfile.php. If you have syntax error, it will give you a line-number
     (as opposed to running via the web, which will just quit w/o any output).
  2. Start your file with the following:

     <?php error_reporting(E_ALL|E_STRICT); ini_set('display_errors', 'stderr'); ini_set('display_startup_errors', true); ?>

     Be aware though:
     • You want to put these right near the start of your file, of course. It doesn't do good to turn on error-reporting on line 20, if you first have an error on line 10!
     • A Gotcha: even if the first line of your program turns on error-reporting, your script might crash w/o notice (or line-number)?!

       Reason: Before the first line of your program is run, php parses your entire file. If you have a missing semicolon on line 20, then line 1 will never even be run.

       Solutions:

       1. Run from the command-line, before trying to run it via the web¹.
       2. Make a shell file which simply calls error_report, and then require the file with your real code! In practice, this is kinda clunky.
       3. Set these configuration options in .htaccess, Apache's per-directory configuration file.
       In practice, I do both (a) and (c).

     • Calling ini_set has no effect on the current php process — it will only effect any files you include. (But that's enough reason to do it.)
     • For php 5.4, E_ALL already subsumes E_STRICT. However

       php.radford.edu

       is running php 5.3.
     • Even if your program crashes halfway through, there may or may not be output depending on whether the output was being buffered. (See flush, to manually flush the output-buffer.)
• (optional) 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.

• (optional) Error Reporting Constants
  • E_NOTICE
  • E_WARNING
  • E_PARSE
  • E_ERROR
  • E_ALL
  • E_STRICT (the only one not supported 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_report( $level )) by bitwise-ORing (“|”) various constants. legal error flags; It is recommended to use error_report(E_ALL|E_STRICT).

  See also various error functions.

• Printing from php:

  We can shorten silly-page_php.txt to silly-page-v2_php.txt.
  (Self-quiz: Why can't I do a show-source of silly-page.php, to see the php code?)

  Compare echoing “\n” vs “<br />”.

• php echo vs. print: The latter is a function (takes one input, and returns a boolean). You'd think I prefer print, because it conceivably composes with other functions (albeit after yielding a side-effect). But in practice I find I use echo: I prefer using (any number of) , to echo multiple items (rather than . to string-append), and I never (want to) use the result from a side-effecting function.
• Looking at silly-page-v2_php.txt: examine the use of single-quote vs. double-quote. Let's evaluate:

  "hello" . 17 'hello' "he'llo" 'he"llo' $myName = "Ian" "hello, $myName.\nBye." 'hello, $myName.\nBye' strlen("hi\n") strlen('hi\n')

  Take-away: I recommend using " for your php strings; when you create strings containing html, that html will use ' for its attribute-values. This convention minimizes conflicts between php strings and html(javascript) values, and lets you use php's variable-substitution.

Note: Arguably, php, with all its flaws, owes its success entirely to: (a) that variable-substitution, and (b) the convention that anything not inside a php processing-instruction should be literal output. (FWIW, a better way to blend code with large amoutns of literal-text-data is racket's “scribble” syntax: it nests better, and generalizes better.)

XHTML

xhtml : Even though original HTML doesn't require the following, they are best practices, and they are required for this class:

• Tag names are case-sensitive (with a preference for lower-case and camelCase).
• quote all attribute-values, even if it looks numeric;
• well-formed (duh): each open-tag must be eventually followed by a corresponding close-tag, and if a tag's body contains another open-tag it must also contain the corresponding close-tag.
  • Bad: This is <em>not <strong>at all</em> legal</strong> XML.
  • Good:This is <em>actually <strong>very</strong> good</em> practice.
  Another way of viewing this: The open/close tags must correspond to a tree.

  The most common (non-X)HTML example using improperly nested tags is <p>, which (in HTML) doesn't need to be closed; the browser auto-closes the tag when it reaches the next <p> (or more precisely: when it reaches the next block-level open-tag, or a close-tag which is terminating the enclosing block, e.g. if the paragraph was already inside an itemized list).

  Browsers tend to go to great lengths to try to make sense of tag soup; just because a page looks fine in your browser doesn't mean it's legal. The result is that many people learned their HTML by doing a show-source on bad, illegal examples, and then propagating that bad HTML, and never realizing it because most browsers still did something reasonable (although the details of how a browser handled bad HTML are of course entirely non-standard).

• Self-closing tags:
  • <br></br>— fine, but long-winded.
  • <br/>— self-closing tag, allowed by XML.
  • <br />— Best practice²: used for backwards compatability. The original HTML required a space before the /, and it's conceivable (if unlikely) that a modern browser will insist on using the HTML standard
  • <br> </br>— (note the space inside the tag) this version is not equivalent (and, not valid HTML) — spaces are part of your XML text, even if an HTML browser chooses often ignore them for layout purposes.

  Important: In HTML (and enforced by most modern browsers), you can only use the self-closing tag, for those tags which never are allowed a body. For tags that may or may not have a body (notably: script), you cannot use the self-closing version even when you want an empty body. There is no good reason for this!

  • <hr />— fine; hr never has a body.
  • <img src="foo.jpg" />— fine; img never has a body.
  • <script type="text/javascript" src="foo.jpg"></script>— fine.
  • <script type="text/javascript" >callSomeFunction();</script>— fine.
  • <script type="text/javascript" src="foo.jpg" />— BAD; a browser may ignore the tag entirely!, which is an annoyingly difficult bug to track down.

See also: xhtml.com/en/future/x-html-5-versus-xhtml-2/.

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

©2014, Ian Barland, Radford University Last modified 2014.Oct.06 (Mon)

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