Beginning the Process of Writing Scripts
- Initial Decisions
- Starting Your Script
- Your First Script
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
In This Chapter
-
Initial Decisions
-
Starting Your Script
-
Your First Script
Over the first two chapters we have taken a look at JavaScript and how it fits into the Internet picture. We have given you insight into what you can do with the language and how it works with XHTML, and have talked about browser support. We have approached the language from a coder's perspective by helping you understand the tools you will need to get started.
Now we are going to tackle the task of writing your first scripts, which is what excites us all. We are going to keep it simple for a specific purpose—to build a solid foundation on good programming practices. We will cover each step of creating this simple example in detail, so that we do not have to cover the longer examples in as much detail later in the book.
To do this, we are going to approach your first script the right way. By the right way, we mean that we are going to plan the script, implement it, and test it properly. While doing this, we will also remind you of some of the things you learned in the first two chapters.
Initial Decisions
First, remember that JavaScript is embedded into XHTML documents by using the <script> element. As the browser is loading the page, it begins interpreting the code, starting with the first line of the script and processing everything that follows until it reaches the end. This is true whether the code is inline or it is pulled from an external library (.js) file.
JavaScript interprets each line of code into instructions it then uses to perform specified tasks. It is the same as following directions to a party, for example. Just as you would read each instruction and act on it by turning or driving your car in the appropriate direction, JavaScript follows each of your instructions in order.
On your way to the party, you might need to stop at a red light, or you might need to pick up a friend. These types of rules you can also emulate with JavaScript. For instance, you may want the browser to sit idle until some kind of event, such as a mouse click, happens.
Before you even start writing your code, you do have to make some initial decisions. These decisions will help you better understand what you have to do and how to write your code. The following sections will step you through this process with the objective of helping you understand the questions you should be asking yourself that ultimately lead to the creation of successful code.
What Browsers Do You Want to Support?
The first question you need to ask is, "What browsers do you want or need to support?" This is a huge question because it will determine how much code you need to write. As we said previously, JavaScript has changed drastically over the first several versions of the language. So it is important to know what syntax is available to you when writing your scripts.
In fact, the language had a tendency to be all over the map until the ECMAScript standard was released. Because ECMAScript defines only the core portion of the language, however, it still leaves a lot of gray areas in client-side and server-side implementations. Because of this, you are going to spend a substantial amount of time trying to write scripts that work in all browsers. Hence the question, "What browsers do you want to support?"
In deciding what browsers you want to support, there are several factors that can help. They are as follows:
Do you have server-side functionality to help you determine the browser before pages are returned to the browser?
Do unsupported browsers need to fail gracefully?
Help from the Server Side
If you are able to determine the browser making the request, you have a major advantage when creating client-side JavaScript programs. This allows you to avoid potential client-side errors by not sending code that is not supported. This is especially key because many of today's popular browsers have different versions that support different standards.
True, it might mean that you need several versions of your scripts, but the amount of download time for the browser and the chance of error will be greatly reduced. You are no longer sending code to determine the requesting browser because the excess lines needed to perform "client sniffing" are no longer needed. Having this functionality also allows you to better handle known non-supporting browsers gracefully.
Failing Gracefully
The second question has to do with how gracefully you want to handle non-JavaScript browsers. This would include not only browsers that do not have JavaScript support, but also those that have it turned off.
CAUTION
If you have ever taken a look at the preferences of your browser, you will notice that you can turn off JavaScript. See Figure 3.1 for Mozilla 1.0's Preferences dialog box, where you can turn off JavaScript. This is important to keep in mind, because you will need to be able to handle instances with JavaScript turned off gracefully. To do so, simply treat these instances as browsers that do not support JavaScript at all.
){kind=link}
When asking yourself this question, you need to understand your true objective. Are you building a site that you want all people to access and get the full experience? Maybe you are developing an intranet for a company, and your users will only have one browser. Or you may just be building a sample site to see what you can do with JavaScript.
By going through this exercise, you are determining the type of restrictions that need to be placed on your users. Be sure to make this decision carefully and with the full understanding that leaving out some people may mean leaving out a percentage of potential users. If you have made the decision not to support users who do not have JavaScript enabled, your task will be a bit easier—simply do not provide secondary XHTML for these users. Otherwise, you should try to provide them with as much functionality as possible with the intention of not compromising your content.
How Do You Want to Handle Non-JavaScript Browsers?
Up to this point, we have not talked about how to actually handle browsers that do not support JavaScript or have it turned off. If you have the ability, you can eliminate some of your worries by using the server-side functionality we spoke of earlier; however, this does not solve the problem of those browsers that have JavaScript turned off. But there is hope: the <noscript> element.
The <noscript> element allows you to specify additional XHTML to be displayed when JavaScript is turned off or not supported. This element and its included code usually go directly under any <script> sections you may have. Listing 3.1 shows how you can use this element, and Figure 3.2 shows how this is rendered in Mozilla with JavaScript turned off.
){kind=link}
Listing 3.1 Using the <noscript> Tag
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<title>My First JavaScript Script</title>
</head>
<body>
<h1>What is returned?</h1>
<p>
<script type="text/javascript">
document.write('JavaScript is turned on!');
</script>
</p>
<noscript>
<p>JavaScript is turned off!</p>
</noscript>
</body>
</html>
If you look at Listing 3.1 and Figure 3.2, you will notice that the <noscript> section tells the user that JavaScript is turned off. If it were turned on, this same page would interpret the JavaScript code and ignore the <noscript> section, as shown in Figure 3.3. This is a great tag to help handle non-supporting browsers gracefully.
Figure 3.2 Rendering the <noscript> tag.){kind=link}
Figure 3.3 Listing 3.1 with JavaScript turned on.
CAUTION
Some of the older browsers, such as Navigator 2 and early versions of Internet Explorer, do not support the <noscript> tag. We have also seen problems with using this tag multiple times on a page with older browsers that support JavaScript, but have it turned off.
Inline or src It?
The final question you need to ask is, "How do you want to put it on the page?" The question is a determination of where you want to put all of your code. This can either be in external library files that have been included using the src attribute, or directly in the document itself.
As we mentioned before, by placing your code in an external file, you will be able to edit one file to affect scripts on all of your pages. Additionally, if your code contains the characters < or &, it will not properly validate if you are attempting to create valid XHTML documents. Although this is not a problem for most implementations today, the momentum XHTML has in the market, from a standards perspective, could easily make this a requirement in the near future.
We recommend that you put all of your functions in external source files, which solves these problems. We even recommend you split up functions into separate files according to their functionality. For instance, you might have one file called calculations.js that contains reusable calculations, but another file called formhandling.js that contains form handling functions.
NOTE
The src attribute was not supported until JavaScript 1.1, which means that Navigator 3+ and Internet Explorer 4+ support it fully. Additionally, Internet Explorer 3.02 did attempt to support this method of referencing external scripts, but we have had limited success in getting it to work. The good news is that these older browsers represent only some fraction of 1% of users, although we do feel it is important to point out this information.
What Are Your Objectives?
The process of defining objectives is among the most overlooked steps in starting a project. You would expect it to be the first and most thorough step, but often it is not completed successfully or fully. We have all seen many JavaScript programmers approach a script from what we call the cool angle rather than the functional angle.
JavaScript is definitely "cool," and if the cool factor is your main objective, go for it. However, if your main objective is to provide solid and useful functionality, try to avoid excess and unnecessary coding. In the long run, other programmers and even you will find it hard to follow your code if you have a lot of "cool" features that offer no real value. You will also find it difficult to implement changes and fixes, because you will have to program around your cool code.
When defining your objectives, you fully determine your objectives and ultimately the end result of your program. For instance, you may want it to perform error checking on forms. With this goal in mind, you should work backward to determine what will accomplish this goal. Using the form example, you should ask yourself how many elements are going to be in the form? How many are radio buttons, text fields, selection options, and so on that you want to be able to process?
After you have nailed down this second level of objectives, you can start figuring out how to code your scripts. You will want to write code that handles the radio buttons, text fields, and selection options. You may be able to create a function that will cover all the functionality you need and that simply works from a parameter passed in, such as "radio" to signify the handling of a radio button. Remember that code reuse is a good thing and that you should apply any coding experience you have to reducing the number of lines of code your scripts need.