Using CGI Scripts

CGI scripts are similar to any computer program: they are instructions to a computer that are written in one of the many existing high-level languages. In fact, a CGI script can be written in any kind of computer language, high- or low-level, or even in the language of a shell as those that exist for the Unix operating system. Yet, high-level interpreted languages are preferred, the most popular one being the Perl language.

An interpreted program (or script) is a program that depends on another program, called the interpreter, which reads the script and translates it to machine instructions. Thus, when we talk of Perl, with a capital P, we are talking about the definition of a computer programming language. If we mention "perl"--without capitalizing the word--we are referring to a program (called interpreter) that, running in a computer, will read line by line our Perl script, and will handle to the computer the adequate instructions for the task we want to be performed.

In reality, though we may talk, for the sake of simplicity, of "running a Perl script," it is the interpreter that is really running. Therefore, interpreted programs, also called "scripts", are different from those programs that consist of real machine instructions. A question may come to mind, which machine runs the interpreter: the server or the client? The answer is either one, which creates a further division.

Client and server scripts

When a script is interpreted by an interpreter running in a server, we talk of a "server script." When a script is interpreted by an interpreter running in a client machine, we talk of a "client script." Of course, when the machine in question is acting neither as a server nor as a client, then the script is just a script.

Perl is a typical example of server-side language. However, alternatives exist of other languages on the server side. A Perl script's name usually ends with the extension "pl" or "cgi". The extension "pl" is a generic extension for Perl scripts, and the extension "cgi" is a generic extension for server scripts compliant with the CGI specification.

An example of a language designed for writing client scripts is JavaScript. It was developed to be embedded in the HTML code of a Web page, and to be interpreted in the client machine by the browser software. The Web server sends to the browser the page with embedded JavaScript as a normal HTML page, and it is the browser's responsibility to know how to interpret the HTML and the JavaScript portions of the page.

Client-side programming has experienced great improvements in later times, evolving into what is called dynamic HTML (DHTML) as a result of newer specifications of the JavaScript object model and the World Wide Web Consortium (W3C) style-sheets.

The existence of two types of scripting has its cause in the client-server paradigm and the specification of the HTTP protocol. The client-server paradigm aims at the separation of tasks to lessen the load in the client machine and the server machine, performing in each one those tasks that are more appropriate for that environment. A common example is that of database querying: the query prepared at the client is sent to the server that performs the searching of the database and returns the data so obtained. The client then displays these data to the user in a suitable form.

The HTTP protocol follows this paradigm in that it returns an HTML page which will be displayed in a different way for each user according to the preferences that the user has set up in the browser (navigator) program. However, HTTP introduces an additional complication because each client-server interaction is independent of all the others. No interaction was intended to occur between the user and the server, besides the requesting and the sending of pages. We must remember that forms (the first rudimentary way of reverting the information flow) were only introduced in HTML version 2. This makes that certain tasks can only be performed at the client side or at the server side.

Furthermore, the original concept behind the World Wide Web (or the HTTP protocol on which it functions) was that the pages sent out by the server should provide raw data and hints about how the data should be displayed (the HTML tags). Consequently, client-side processing was reduced to render HTML pages until the introduction of JavaScript. Client-side scripting then began its own evolution, but, until recently, there was not much that the browser (JavaScript engine included) could do with the page. It is true that modern browsers permit the user a greater deal of configuration than before. However, the sharp separation set by the HTTP protocol between clients and servers (that are only allowed to communicate through a limited set of predefined headers) makes that most of what happens in the client side is unknown at the server side.

So, there are facts about the user environment that the server script cannot know and that limit the range of what it can do concerning the display of the pages, making more difficult the building of dynamic pages. This situation can only be dealt with when the page is already sent and it is in the client side. The Web programmer must, therefore, make use of a mix of client and server programming, preparing beforehand all he can at the server side and deferring all he cannot prepare to be processed by a client-side script.

The joint use of a client-side programming language (JavaScript) and a server-side programming language (Perl or another one) is the best alternative to meet the requirements of current Web programming. This is particularly true in applications where the user does something more complicated than merely browsing pre-made pages, as for example e-commerce applications.

Previous | Contents | Next

	| HOME | FEEDBACK | BOOKMARK | Build your Website © 1999-2008 Hector Castro -- All rights reserved