5.2. Cross-Browser DOM
Now that we have either classic frames or iframes, we have reached one of the most widespread reasons for their avoidance: the matter of access. Short of a crystal ball and tea leaves, or maybe two soup cans and a piece of string, just how do the various frames communicate? I've worked with some web developers who believed that it was easier to talk with the ghost of Elvis than to have individual frames communicate with one another. However, to be honest, most of those web developers talked of black helicopters and wore aluminum foil hats to ward off mind control.
As formidable as the DOM sounds, it is nothing more than a hierarchical representation of a document, which, in this case, is an HTML document. Think treesthe data structure trees, not the green woody things. And, no, not binary trees; we want the ones that can have more than two children.
Just in case you need a little refresher in the structure of trees, it goes like this:
However, you must remember one thing when accessing the Document Object Model: Here be monsters. This is one of those places where it is really necessary to test things on several different browsers. The reason for this is the usual; it is basically a question of interpretation of the World Wide Web Consortium's DOM specifications. This might sound a little like the schisms that occur between different sects of the same religion, but depending on the application, it can cause some major headaches. Listing 5-2 shows an example of this potential problem.
Listing 5-2. Example of a Problem Created by Differing Interpretations of the W3C's DOM Specs
Listing 5-3. Microsoft Internet Explorer
Listing 5-5. Opera
Interesting, isn't it? You can't even play the Sesame Street "One of these things ain't like the other" song because none of them is like the others. However, more similarities exist than differences, such as the basic structure and the existence of specific nodes. What is important to remember is that, depending on the web browser, #TEXT elements can be sprinkled here and there.
Listing 5-6. Sample HTML Document
Pencils down. The correct answer is: all of them. Yes, it is a trick question, but it points out that there are many ways to reach the same destination. Think of it as an "All roads lead to Rome" thing, and no one will get hurt. Of course, it might be important to remember that some of the routes to a destination could be quicker than others.
I'd like to cover one additional, often overlooked, DOM topic. When dealing with frames, there will always be more than one #document. Not only does the frameset have a #document, but each frame will have a #document of its own.
Let's say, for instance, that you've got a website that uses a handful of standard-sized pop-ups. Well, rather than code them each by hand and possibly have typos on a few pages, why not create an object to open a number of standard-sized windows? Three different-sized pop-ups should suffice; add to that the capability to override the various properties, and we end up with the "function," which is really a class shown in Listing 5-7.
As with the more traditional languages, to use our window object, it is necessary to instantiate the classin other words, create an instance of the class. Listing 5-8 shows how instantiation is accomplished, and Figure 5-1 displays the result.
Figure 5-1. childWindow class in action
Listing 5-8. Example of Using the childWindow Class
Nevertheless, sometimes recursion is the easiest way to handle a particular coding issue. And not computing Fibonacci numbers or the factorial of a number, which are those "make work tasks" designed to keep computer science professors off the street. Group those two problems with singly- and doubly-linked lists, and they're good for a whole semester.
Listing 5-9. Listing 5-2 Repeated
5.2.2. A Problem to Be Solved
With all due respect to one of my previous managers who believed that there were no such thing as problems, only opportunities, there is one problem that I've been meaning to solve for a while now. It's one of those things that the average person, one without mad scientist tendencies, doesn't realize exists. Where do mad scientists shop online? Oh, sure, there's Amazon.com and Walmart.com, but have you ever tried to purchase a cask of Amontillado, or stones and mortar from either website? These essential tools of the trade just aren't readily available online.
The big websites just don't appreciate the needs of the lonely mad scientist. In fact, it might be a good idea to include some of the other often-underrepresented groups as well. I imagine that alchemists and sorcerers have some issues shopping for the tools of their trades as well. I, for one, have never seen either site offer retorts or grimoires or anything along those lines. Not that I know what a retort is; I imagine that it is some kind of backup Linzer torte or something along those lines. There is definitely an untapped market here, so much so that, had I conceived of this idea about six years ago, it would be necessary to beat off potential investors with a stick.
I envision this website as a pretty normal series of web pages, starting with a splash page that takes the visitor to a page displaying items for the various guilds: mad scientist, alchemist, and sorcerer. The visitor would then have the option of browsing all the items available or filtering by guild.
Shoppers could view the details of the individual items and, if desired, add them to their shopping cart, which can be displayed at any time. When they were sure that they had everything they want, they could proceed to checkout, enter their shipping and billing information, and be off.
So with that idea in mind, the various web pages fall into a few simple categories:
Oh, and the other thing I forgot to mention: This site needs to work with a selection of different web browsers. I have a couple of totally logical reasons to require this cross-browser capability. The first reason is to appeal to as wide a customer base as possible because the more customers, the more sales. The second is, it might not be a good idea to tick off someone who is potentially creating a Moon-Mounted Death Ray. Hmm, note to self: Use a P.O. Box as a corporate address.
Before proceeding any further, now is a good time to delve a little into the server-side environment. Let's start with the operating system and web server; I'm using Windows XP Professional and Internet Information Server. The reason for this is the usual: It came on the machine, and I'm too lazy to change it. Besides, I'm pretty sure that "Age of Mythology" doesn't run on Linux. Note to self: Make sure that you don't get caught by Mary Ann playing when you should be writing.
So far, my environmental choices have been pretty boring, and the open source people are thinking that Firefox alone doesn't cut it for a book. Alright, how about MySQL version 5? In fact how, about MySQL version 5 with stored procedures? Interested? Well, then, read on.
In version 5, MySQL introduced a feature that had been in the proprietary databases for quite some time: stored procedures. Just in case you were abducted by aliens in 1974 and only recently got back to Earth, let me explain what stored procedures are. Stored procedures are preparsed SQL that accepts parameters and can return results.
Let's say, for example, that we have a table consisting of the states and territories of the United States and the provinces of Canada. Let's also say that we'd like the option of passing the procedure a two-character abbreviation to receive the name of the state or province, or passing a null value to obtain the names and abbreviations of all. We would create a stored procedure that looks a lot like the one shown in Listing 5-10.
Listing 5-10. A MySQL Stored Procedure
Now that we have a stored procedure, the big question is, what do we do with it? Fortunately, that's an easy question; we call it as shown in the first example here. However, I'd like to point out that because of the way the stored procedure is called, when a parameter is null, a null must, in fact, be passed as shown in the second example.
CALL stateSelect('NJ'); CALL stateSelect(NULL);
Now that the database issue is out of the way, it is time to figure out what to code the server side in. My first thought was to pick a language that has a proven track record and was widely accepted, but I could not find a reliable source of punch cards, so COBOL wasn't a viable option. The really scary part is that I've seen it attempted at companies because they thought that they could port their mainframe CICS code to the Web, but that is another story.
I finally decided on PHP 5. My reasons for this are several. The first is that I've seen it and know that, not only does it work, but it works well. Another reason is that it appears to be a combination of C and UNIX Shell, both of which I've worked with in the past. The third reason is that it plays well with MySQL and stored proceduresat least, once configured correctly and if I remember to use the mysqli library instead of the older mysql library.