Scripting: An Introduction

In General

Although it seems scripting seems not for the faint of heart, a little can go a long way. This is how you do the fun stuff. Scripting allows for greater interactivity, and more dynamic pages.

There are two very basic types of scripting: front-end, or client-side, and back-end, or server-side. They are different, but not mutually exclusive. Neither is a total solution in every case for every situation. Often times they are used together. Validating forms, for example, is often done using client-side scripting to make sure the form is filled out, and then server-side to ensure the form is filled out correctly. This section will look at both, but neither to the point of exhaustion. The methods and tools used here are not the only way of doing things, but they are a way.

This section is intended as an introduction, a getting-wet-of-feet, a demonstration. There is much to do and much to do with scripting. Hopefully the information here will lead to bigger and better things.

There is some new buzz in the world of web design and programming (as usual), and the two most prominent also have to do with scripting/programming, and those are AJAX (or Ajax) and Ruby on Rails. Both are being used to create very dynamic, responsive sites. As much as anything, this is the buzz (spring 2005) that is causing the same kind of excitement in the house that CSS and standards did a couple of years ago…

Client-Side Scripting

Client-side scripting is where scripts take effect on the client, or viewer/reader’s machine. A typical example of this is the image rollover, where the viewer moves their cursor over an image, and a script reacts to that event and changes the image. This does not require interaction with the server, once the parts are loaded onto the client machine. Client-side scripting is generally handled using JavaScript, or JavaScript’s big cousin ECMAScript.

Current best practices are moving to what is referred to as DOM scripting, and moving away from any JavaScript embedded (or inline event handlers) into a document. DOM scripting, and unobtrusive JavaScript (to use the term used by Christian Heilmann) make a lot of sense, and the implementation is really no more difficult. A very good intro to these techniques are found in DOM Scripting by Jeremy Keith (1-59059-533-5).

The ideas behind the implementation of DOM scripting are very much like those behind CSS, and CSS’s separation of content and presentation. Here, though, we are talking about separating scripts from content. This has the same advantages as style sheets: easier maintenance and reusability. It also treats scripting in a more figurative fashion as the enhancement it should be, rather than any kind of critical functionality.

DOM Scripting is also aimed at the particulars of how the Document Object Model works. That is, is addresses things intrinsic to the DOM, while maintaining a graceful downgrade, in the case of the scripting. not being able to function.

Also of invaluable assistance is JavaScript: The Definitive Guide, Fourth Edition, by David Flanagan (5e 2006), although somewhat to early to get in on the unobtrusive goodness, has is a great reference for JavaScript up to v1.5. I would suspect there may be a 5th edition underway.

One thing to be very sure of when scripting: testing is paramount. With JavaScript, Firefox has, in its toolbox menu, a JavaScript console. It works much like a syntax checker, at the least giving you a file and line number where an error occurs. Safari has a similar implementation, although you need to have the Developer Tools installed. If you do (they are on the OS install CD), open a Terminal session, and type in the following: defaults write com.apple.Safari IncludeDebugMenu YES. Hit return, restart Safari, and there will be a new Debug menu. Among a lot of other things, about halfway down, is a Show JavaScript console. These tools will help, and as much browser/platform testing you can do will help more.

TOC: Client-Side

Server-Side Scripting

Server-side scripting can most easily be thought of as an exchange between the client and the server. Most often seen with the use of forms, server-side is used for everything from giving you the time of day to running major enterprises like Amazon.com. Although not required by any means, server-side scripting or programming may include interaction with a database (or many databases). Server-side is often referred to as back-end, as opposes to client-side front-end. You see the front, but you don’t see the back.

There are a whole lot of combinations for server-side. A whole lot. A common combination, and one that is easy enough to implement, gives you the basic idea of the whole process, and is free (as in open source and beer), is referred to as LAMP. LAMP stands for Linux/Apache/MySQL/php (or perl, or python). In order, this is your operating system (a Unix flavor), your server, your database, and your scripting/programming language used to glue them all together.

Server-side programming is written is (as indicated above) Perl, Python, Ruby, and several other languages. I like PHP (or php). I’ve messed with Perl, and poked some sticks at Ruby, but php has been what I’ve worked with most, and that’s what I’ll be using here.

TOC: Server-Side