| You should now prepare for a change of direction. After looking at Web page design, and as we get deeper into creating Web applications, we are going to look at the other side of the Web application coin server-side programming. Everything we have used Dreamweaver MX for so far has been working inside the user's browser. HTML for page design, Flash for multimedia effects, and JavaScript behaviors for greater interactivity are all client-side technologies designed to take advantage of modern browser capabilities. The use of these client-side technologies is vital for the use of any Web site. However if you want your pages to interact with a database or give customized responses to each user, you have to look at server-side scripting. Only by running a program on the Web server itself can you connect up to a database, display a page counter or guest book, or serve different pages to different types of browsers and platforms. To do this, you need to send information from the user's browser, through the Web server, to a program that processes the information before sending it back via the server to the user's browser. The Eternal Problem of the Web Using client-side technologies is usually a little easier than writing code for the server (despite the enormous amount of help we can get from Dreamweaver), but you are generally sending your pages "into the great unknown." A request is made and the page is returned to the browser without us knowing anything about the computer type, browser software, or what additional plug-ins and other software is available to that user. This may be a very sophisticated page, such as a Flash movie that interacts with the user, but unless the browser has been sent all the information it needs, and it can understand that information, the page won't work. A plain HTML page provides a stark illustration of this problem. The HTML in the page never changes and is the same for every user that requests that page. If the page includes tags such as <FRAME> or (whispering this very quietly) <blink> or <marquee>, some users will get the page displayed quite differently from what you intended, while other users will see the page correctly. Dreamweaver produces clean HTML code that displays well in most of the browsers in use. But ultimately, there is little you can do to help users who have unusual, or unexpected, configurations. (The golden rule of Web design is that there is never a "wrong" browser, only "wrong" pages!) NOTE You can use a JavaScript behavior to redirect users to different pages, depending on their browser type, but this is not the best solution. This means that every correction and update must be done on at least two, possibly three, pages a recipe for mistakes and inconsistency.
CGI to the Rescue Imagine, though, if the page could contain different HTML tags, depending on the type of browser that requested it. To do this you would need to find out the browser type from the request and process the page on the server before it is sent to the user's browser. Since the beginning of the World Wide Web, page designers have wanted to do this sort of thing, and to do so, they have turned to CGI, which stands for Common Gateway Interface. It is not a programming language, but a set of rules for how a Web server talks to a program running on it. HTML forms control how information is sent from a browser to the Web server and which script or program will process it. CGI controls how that script works and how information is sent through the server back to the browser. In the CGI world, the server acts as a gateway between a program and the client. CGI programs can be written in any programming language that the Web server understands, but many server scripts are written in the Perl language. We will look at Perl in a bit more detail later, but for now all you need to know about Perl is that it's very good at handling strings of text, and it also gets on well with Unix, the traditional operating system of Web servers. It is these two factors that have made Perl popular as the Web has developed. | 
