Server side Scripting
A script is a form of a program (like any other program you are used to using).
As it implies, server side scripts are scripts on a page that depend on the server to carry out the desired action.
Server-side scripting is a method of designing websites so that the process or user request is run on the originating server.
Server-side scripts provide an interface to the user and are used to limit access to proprietary data and help keep control of the script source code.
Server-side scripting is about "programming" the behavior of the server.
This is called server-side scripting or server scripting.
Normally, when a browser requests an HTML file, the server returns the file.
However, if the file contains a server-side script,
the script is executed on the server before the file is returned to the browser as plain HTML.
is a standardized way of sending information between a server and the script.
Most web hosting services offer a library of standard Common Gateway Interface (GCI) scripts that are already on their servers.
If your server has a CGI script that you can use, you only need to follow the instructions and load the necessary script to your pages.
ITS has some CGI scripts available for use, but normally these scripts are not released the the general public.
A CGI script is a program (usually written in the Perl programming language) that communicates with the server in a standardized (or CGI-like) way.
If your server does not have a CGI script that you need, there are a number of resources for other CGI scripts on the web.
You can find lots of free CGI scripts written in Perl all over the web.
However, servers are leery of allowing just any old CGI script to be added to their capacity,
so you might have to negotiate with your provider to use a CGI script that you find on the web.
Issues with CGI scripts
They are not secure and some ISPs don't allow them on their servers.
If you want more information on how CGI scripts can make you vulnerable, try What's the problem with CGI scripts?
But, understanding their limitations and challenges, CGI scripts might be just what you need to collect data from visitors to your site.
What does the CGI Script do?
Each element on your form has a
NAME and a
VALUE associated with it.
The name identifies the data being sent.
The value is the data being sent.
Scripts use the name-value pairs to:
Separate them into individual intelligible pieces.
Do something with the data.
The discussion below is just an example of what you could do
if you had access to a server that permitted CGI scripts,
and OPAL does not
If you have access to ITS server-side scripts, you can create forms by following ITS's instructions
If you want to have a way to ask questions and get
responses from people who view your web site, follow ITS's
Creating Forms Using Mailform.
The key here is that in a
server-side script, you need the server to capture and do
something with the user input. Thus you need to deal with
the server to make your script conform to its way of doing
things. You need to add the relevant script to your pages,
but you also need to deal with the server to have the server
do something with the input (display, store, file, send, etc.).
How Forms Work
Creating a working form has two steps:
① First, create (or just know about) a script on a server that processes the output of your form.
Generally, this step is taken care of by an existing script that the WWW server administrator has placed on a server.
You identify the server script you want to use in the action attribute of the form element, like this:
The <form> tag declares the existence of a form.
There are two attributes here of which we must be aware: the
attribute and the
attribute tells the form to post the data that it receives in one of two ways.
We are using the
"post" value here.
attribute specifies what program to use to process the data received in the form.
In this case the action is specified as:
② Second, write an HTML page with the form elements in it.
If you don't have one to use, we can
practice with this page.
This is the page that the users will see and on which they enter
information. Since this page is in HTML, it is
the same no matter what server script will
process the input from this form. One of the
considerations you will have to make is to
decide how you want the user to make an input
into your form.
A key idea in this step is that each
"piece" or element of the form has a
Consider the HTML tags below, which
creates a series of button input types.
Note that the
attribute for each input
type is set to
When the server-side script processes the user input, it will associate the
selected by the user with the variable
Checkbox Input Type
With the checkbox
we have a list of items that will appear
in our form with a small checkbox in front of the text. We
can "check" as many of the boxes as we like. Notice the
that we assign to each of these input boxes is the same. We
are using the same value here because our respondents can
choose one or many of these choices. By giving them all the same
we can see all that they checked when we receive the data. The
tells the form what to list when we receive the data. Here
we want to use names that uniquely identify each item. The
tells the browser which one to initially select (i.e., when
the page loads, this item will already have a check in its box).
<p>These are my favorite schools </p>
value="John Tyler Community College"
/>John Tyler Community College
value="Cal State-Monterey Bay"
/>Cal State-Monterey Bay
The above code results in the following (any or all of the boxes in this group may be selected):
The <select> tag creates a drop-down box, which is similar to the
"radio" type of input in that we are offered a number of items
from which we can choose only one.
The display of these items, however, is significantly different.
The <option> tag allows us to enter list items which will appear as a single input box
with a drop-down list of items from which
the user can choose only one.
The <option> tag with the selected attribute
will appear first in the text box when the page is loaded in the browser window.
Again, the name attribute will be used later when we receive our data.
<p>On Saturdays, I usually play:
The above code results in the following (only one button in this group can be chosen)
Using other server-side scripts
Google offers some scripts that can be embedded in your code for your purposes.
If your template came with a search tool, but no search functionality,
you might want to try Google's Custom Search Engine.
If you are interested in the analytics of your site,
you might want to try Google Analytics.
A bit more challenging, but not impossible to do, are Google Forms.
Using the online tool, you can generate some code you can copy and add to your pages.
But where is the server in this server-side scripting?