Please send questions to
st10@humboldt.edu .
Week 6 Session - on Sessions! - 11-16-06
* schedule shift: will talk about SESSIONS (and hidden fields)
(hidden parameters?) tonight, and PHP and mySQL (hopefully!!)
the Tuesday after Thanksgiving;
* start: hidden fields/hidden parameters
* a convenient way to pass some info to whatever is processing
a form...
* (caveat: not good for sensitive data like password and
credit card numbers!!! can still be sniffed, etc.)
* another <input> tag, and the type is "hidden"
... then, when the form is submitted, the hidden
"component's" name and value are passed along with the
other form data
* for example:
<input type="hidden" name="_submit_check" value="1">
* THEN, it is safe to have a check such as
if ($_POST['_submit_check'])
... since _submit_check never can be a value which could
be mistaken for false (if you've set up the hidden
parameter as shown above)
* SO: see try_hidden1.php for an example
* ASIDE #2: rational structuring for your PHP that generates
and handles forms
* consider your basic PHP page that both displays and
processed a form (taking advantage of the above):
if ($_POST["_submit_check"])
{
// process the submitted form
}
else
{
// display the initial form
}
* David Sklar in "Learning PHP 5", Chapter 6, makes
an excellent point that having functions for "process
the submitted form" and "display the initial form"
has both aesthetic and even a few practical benefits;
if ($_POST["_submit_check"])
{
process_form();
}
else
{
display_form();
}
function process_form()
{
...
}
function display_form()
{
...<input type="hidden" name="_submit_check" value="1">...
}
... let's convert try_hidden1.php to functionalize1.php
* and one more point about such functions...
... it makes it more reasonable to add a "data validation"
stage.
Here's a handy template, for example, that David Sklar gives
in "Learning PHP 5", Chapter 6:
if ($_POST['_submit_check'])
{
if (validate_data())
{
process_form();
}
else
{
display_form();
}
}
else // nothing's been submitted yet!
{
display_form();
}
* note that validate_form() should return true or false
(true if the form is valid...!)
* note that if validate_form() builds an array or something
containing notes about problems it found,
then display_form could see if such notes exist,
and politely display them along with the form so the
user has a clue about how to more effectively try again;
* SO - finally, a few words on SESSIONS!
* first: why do we need sessions?
... because HTTP - hypertext transfer protocol - is STATELESS
* there's no way --- in HTTP alone -- to "connect" two
requests;
* BUT, there are times when we'd like to have multiple
page requests be "connected" --- and we need help external
to HTTP for that.
* Cookies can be used to help save information between requests
so that page "logic" can retrieve that info and perhaps know
what to do next (in a larger "logical" sequence of desired steps)
* SESSIONS are one such way;
* (source: Chapter 8 of "Learning PHP 5" by Sklar)
* in PHP, if you'd like to use a session in a page, you need
to call session_start() at the BEGINNING of that page.
* no, REALLY the beginning --- even before <html>,
even before a blank line!!!
<?php
session_start();
?>
<html>
...
* this is because session_start() actually adds headers,
and NO header info can be sent after ANY of the body
has been sent.
* so --- Sessions use a cookie named PHPSESSID,
and when you call start_session(), the PHP interpreter
then tries to look for the existence of this cookie...
it SETS it if doesn't already exist.
* Once you put this session_start() at the beginning of
a page, session data will be stored in a global array
$_SESSION
* and, you can read these name-value pairs, you can
change them, you can even remove them (just like
any PHP array!)
* first example: try_session1.php
* second example (completed after class, and abandoning the
database-oriented example we started on in-class): try_trio.php