Summary

We've covered a lot of ground in this chapter and have really just scratched the surface of server-side scripting.

In this chapter, we saw that

• Client-side script is script that runs in the client's browser. Server-side script is script that runs on the server after the page is requested, but before it's sent to the browser.

• We looked at the "personal" web server, a free Internet server available for use with Microsoft Windows and available for Windows 9x as Personal Web Server (PWS) and Windows 2000 Professional and Windows XP as Internet Information Server (IIS). It is essentially a cut-down version of the server version of Windows 2000 Server's Internet Information Server (IIS). We looked at where we could obtain IIS and how to install it.

• The server-side scripting environment with IIS is called Active Server Pages. After saving a normal HTML page with the .asp extension, we can then insert script inside the page that will run server-side. Only .asp pages can include server-side processing.

• Inserting server-side script can be done via a normal <script> tag or by using the <% and %> delimiters. The default server-side script language on IIS is VBScript. Therefore, the <script> tag must specify the language attribute as JavaScript, and that the script is to be run at the server using the runat attribute. If we use the <% and %> syntax, we must specify the language of the whole page using the directive <%@ language = JavaScript%> on the page's very top line.

• Server-side script works very much as client-side script does, although we saw that any HTML inside an if statement or a loop is controlled by the JavaScript.

• Whereas client-side scripting uses the Browser Object Model (BOM) to get things done, server-side scripting uses ASP objects, which enable us to get information from the user, write information to pages, and manipulate the server itself.

• The ASP Request object deals with information surrounding a user's request for a page. This includes the browser details, information posted in forms, information sent via a URL, and cookies.

• The Response object allows us to determine the response the user will get. This includes writing information to a page, sending cookies, and even redirecting the user to a different page altogether.

• We looked at the Server object and saw how it allows us to run components on the server. Components are a little like plug-ins for the browser, in that they are code modules installed on the server, which extend its functionality. They may perform tasks such as enabling database access, checking browser capabilities, or more complex tasks, such as sending e-mails and checking credit cards.

• We looked at the concept of a session and how this was objectified in the web server by the Session object. Sessions start with the first request of an ASP page by a user and end twenty minutes after the last page request by the user.

• We can capture the session start and end points in the Session_OnStart and Session_OnEnd events, which need to be placed in the global.asa file.

• The Session object also provides an easy method of storing information for the duration of a session in session variables.

• Finally, we looked briefly at the Application object, which is used to control the actual website. This is similar to the Session object in that it has Application_OnStart and Application_OnEnd events and can be used to store information on the server using application variables.

Try experimenting with the knowledge gained in this chapter. In the next chapter we take server-side scripting even further and look at how we can access databases from a web page. The ability to access a database will enable us to take our website to a completely new dimension.