• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Introduction > JavaScript Approaches in These Applications

JavaScript Approaches in These Applications

Those are the basics. You'll see that I incorporated a couple of these strategies in the applications in this book. I should also mention the JavaScript approaches, or coding conventions. That'll give you a better idea of where I'm coming from, and whether the approaches will work for you.

The first thing I did when considering an application was to decide whether your (and my) web site visitors might have any use for it. Each application solves one or more basic problems. Searching, emailing, online help, setting personal preferences, testing or gathering information, creating image rollovers, and so on are fairly common features that web surfers like. If a potential application didn't pass the justification test, I didn't spend any time on it.

The next thing I did was to decide whether JavaScript could pull off the functionality I wanted. This was pretty easy. If the answer was yes, then I went for it. If not, it was into the JavaScript landfill.

Once I singled out an application, it was off to the text editor. Here are some of the conventions I used for the codes.

Reuse as Much Code as Possible

This is where JavaScript source files come into play. That is, these applications make use of the JavaScript source files loaded in using the following syntax:

<SCRIPT LANGUAGE="JavaScript1.1" SRC="someJSFile.js"></SCRIPT>

someJSFile.js contains code that can be used by multiple scripts—any one that uses the above syntax. Many of the applications throughout the book use JavaScript source files. This just makes sense. Why reinvent the wheel? You can also use JavaScript source files to hide code from the rest of the application. You might find it useful to keep a very large JavaScript array in a source file. Using JavaScript source files are definitely worthwhile, so Chapter 6, is devoted to it.

Some of the applications contain code that is simply cut and pasted from one place to another. This code could easily qualify as a candidate for a source file. I did it this way so you don't have to spend so much time reading: "See the code in the library file three chapters back . . ." This way, the code stays in front of you until you understand it, and cuts down on the page flipping. After you get the apps comfortably running on your site, consider creating a JavaScript source file.

Isolate the JavaScript

Keep as much within a single set of <SCRIPT></SCRIPT> tags as possible between the <HEAD></HEAD> tags.

Declare Global Variables and Arrays near the Top

Even if they are originally set to an empty string or undefined, declaring global variables and arrays at the top of the script is a good way to manage your variables, especially when they are used throughout the script. That way, you don't have to sift through a bunch of code to change a variable value. You know it'll be somewhere near the top.

Declare Constructor Functions After the Global Variables

I generally include functions that create user-defined objects at the top. This is simply because most of my objects are created early in the life of the script.

Define Functions from Top to Bottom in "Chronological" Order

In other words, I try to define functions according to the order in which they will be called in the application. The first function defined in the script is called first, second is called second, and so forth. At times, this can be difficult or even impossible to enforce. This approach, however, at least improves the organization and the chances that adjacent functions will be called in succession.

Each Function Performs a Single Operation

I try to limit each function to performing one distinct operation, such as validating user input, setting or getting cookie info, automating a slideshow, showing or hiding layers, etc. That's a great theory, but it can be tough to apply in every case. In fact, I make several flagrant violations in Chapter 5. The functions perform one basic operation, but wind up dozens of lines in length.

Use as Many Local Variables as Possible

I do this to conserve memory. Since local JavaScript variables die after a function finishes executing, the memory they occupy is returned to the system. If a variable doesn't need to last for the life of the application, I make it local instead of global.

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint