Create a form from within your script and send it to the user. The script can arrange to have itself invoked again to process the form’s contents when the user fills it in and submits it.
Web forms are a convenient way to enable your visitors to submit information such as a set of search keywords, a completed survey result, or a response to a questionnaire. Forms are also beneficial for you as a developer because they provide a structured way to associate data values with names by which to refer to them.
A form begins and ends with
<form>
and
</form>
tags. Between those
tags, you can place other HTML constructs, including special elements
that become input fields in the page that the browser displays. The
<form>
tag that begins a form
should include two attributes, action
and method
. The action
attribute tells the browser what to
do with the form when the user submits it. This will be the URL of the
script that should be invoked to process the form’s contents. The
method
attribute indicates to the
browser what kind of HTTP request it should use to submit the form.
The value will be either get
or
post
, depending on the type of
request you want the form submission to generate. Collecting Web Input discusses the difference
between these two request methods; for now, we’ll always use post
.
Most of the form-based web scripts shown in this chapter share some common behaviors:
When first invoked, the script generates a form and sends it to the user to be filled in.
The action
attribute of
the form points back to the same script, so that when the user
completes the form and submits it, the web server invokes the
script again to process the form’s contents.
The script determines whether it’s being invoked by a user for the first time or whether it should process a submitted form by checking its execution environment to see what input parameters are present. For the initial invocation, the environment will contain none of the parameters named in the form.
This approach isn’t the only one you can adopt, of course. One alternative is to place a form in a static HTML page and have it point to the script that processes the form. Another is to have one script generate the form and a second script process it.
If a form-creating script wants to have itself invoked again
when the user submits the form, it should determine what its own
pathname within the web server tree is and use that value for the
action
attribute of the opening
<form>
tag. For example, if a
script is installed as /cgi-bin/myscript in your web tree, you
could write the <form>
tag
like this:
<form action="/cgi-bin/myscript" method="post">
However, each of our language APIs provides a way for a script to obtain its own pathname. That means no script needs to have its pathname hardwired into it, which gives you greater latitude to install the script where you want.
In Perl scripts, the CGI.pm module provides three methods that are
useful for creating <form>
elements and constructing the action
attribute. start_form()
and end_form()
generate the opening and
closing form tags, and url()
returns the script’s own
pathname. Using these methods, a script generates a form like
this:
print start_form (-action => url (), -method => "post"); # ... generate form elements here ... print end_form ();
start_form()
supplies
a default request method of post
,
so you can omit the method
argument if you’re constructing post
forms.
In Ruby scripts, create a cgi
object, and use its form
method
to generate a form. The method arguments provide the <form>
tag attributes, and the block
following the method call provides the form content. To get the
script pathname, use the SCRIPT_NAME
member of the ENV
hash:
cgi.out { cgi.form("action" => ENV["SCRIPT_NAME"], "method" => "post") { # ... generate form elements here ... } }
The form
method supplies a
default request method of post
,
so you can omit the method
argument if you’re constructing post
forms.
The script pathname is also available from the cgi.script_name
method.
In PHP, a script’s pathname can be obtained from the
PHP_SELF
member of the $HTTP_SERVER_VARS
array or the $_SERVER
array. Unfortunately, checking
multiple sources of
information is a lot of fooling around just to get the script
pathname in a way that works reliably for different versions and
configurations of PHP, so a utility routine to get the path is
useful. The following function, get_self_path()
, shows how to use
$_SERVER
if it’s available and
fall back to $HTTP_SERVER_VARS
otherwise. The function thus prefers the most recently introduced
language features, but still works for scripts running under older
versions of PHP:
function get_self_path () { global $HTTP_SERVER_VARS; $val = NULL; if (isset ($_SERVER["PHP_SELF"])) $val = $_SERVER["PHP_SELF"]; else if (isset ($HTTP_SERVER_VARS["PHP_SELF"])) $val = $HTTP_SERVER_VARS["PHP_SELF"]; return ($val); }
$HTTP_SERVER_VARS
is a
global variable, but must be declared as such explicitly using the
global
keyword if used in a
nonglobal scope (such as within a function). $_SERVER
is a “superglobal”
array and is accessible in any scope without being declared as
global.
The get_self_path()
function is part of the Cookbook_Webutils.php library file located
in the lib directory of the
recipes
distribution. If you
install that file in a directory that PHP searches when looking for
include files, a script can obtain its own pathname and use it to
generate a form as follows:
include "Cookbook_Webutils.php"; $self_path = get_self_path (); print ("<form action="$self_path" method="post"> "); # ... generate form elements here ... print ("</form> ");
The examples shown in this section have an empty body between the opening and closing form tags. For a form to be useful, you’ll need to create body elements that correspond to the types of information that you want to obtain from users. It’s possible to hardwire these elements into a script, but Recipes and describe how MySQL can help you create the elements on the fly based on information stored in your database.
18.218.45.80