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.
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.
Keep as much within a single set of
<SCRIPT></SCRIPT> tags as possible
between the <HEAD></HEAD> tags.
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.
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.
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.
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.
Get JavaScript Application Cookbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
