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.,
as part of the http request.
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 superglobal 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 should be idempotent —
that is, fetching the same request twice should be the same as getting it once.
Even better, they should have no side-effects12.
See a wry tale here.
So if your form
causes a bank transfer to happen,
or adds something to the user's shopping-cart,
or updates a database,
then GET is probably not appropriate.
POST requests are more secure against casual looking over the shoulder
(but still entirely 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. having
a separate URL for each result,
e.g.different xkcd strips.
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 suggest3
“customer-info-form.html”
and
“customer-info-handle.php”.
1
Idempotent is not quite the same as having-no-side-effect:
For example, if you add-to-shopping-cart-unless-item-already-there,
you can change state, but still be idempotent.
↩
2
Well, “irrelevant” state-change is okay:
you can update log files and update cookie-timestamps,
w/o violating the spirit of a GET request.
↩
3
And later, when we talk about sticky-forms,
I'll suggest
“customer-info-edit.html”
which requires either …-form or …-handle.
↩
radford.edu