Everyone wants to carve out their own little niche on the World Wide Web, and accomplishing this is becoming easier every day. It started with service providers that offered space on their systems and an appropriately configured Web server for users to store Web pages, but that still required the user to do most of the scripting and construction.
One new twist on the personal home page is becoming more popular, especially with major sites like Microsoft, Netscape, and even Yahoo-a page that resides on their site that you can customize. Each person who visits that site will see a different page, depending on the options they chose.
If you look around the Web these days, you'll find many major services, such as Microsoft and Yahoo, that are offering you the option to create your own "home page" that's "hosted" on their systems. Unlike having an account on a provider, these home pages have a set number of configuration options, and as far as the server is concerned, they don't take up much physical disk space. In order to understand how this works, it's first necessary to look at what makes up a typical "home page."
When you stop and think about it, in the simplest sense, home pages are really nothing more than collections of information, with what information being decided by the home page owner. Surf the Web a bit and look at some of the various home pages out there, then sit down and try to figure out what they all have in common. You'll probably come up with a list similar to this:
Page characteristics-like background color, text color, and so on.
Some sort of "welcome" message at the top.
Various little interesting bits of information (at least, information the owner deems interesting).
A collection of links the owner likes.
When you create your own home page, you have to write the HTML, find the graphics, and upload everything to your provider. But, if you make some arbitrary decisions about the content of a home page, you can reduce all this work to selecting various options from one or more lists. Effectively, you turn home page creation into an act of configuration instead of construction. Apart from storing the various parameters mentioned, all you need to add is a means for the user to customize or change his or her own configuration.
One of the nice things about basing your home page generator entirely on cookies is that you can create the entire interface through JavaScript and you don't have to require Server-side (Perl) access. In essence, all the parameters defining the page are stored as cookies, and the browser reads this data through JavaScript and dynamically builds the page each time it loads.
Before exploring the process involved, there are some limitations imposed by Netscape's cookie specification that need to be reviewed.
Netscape's proposal for cookies places several limitations on the implementation. The specification states that at most there only needs to be:
With a little creativity, however, you can get around (or, at least, minimize) these limitations.
Custom Domain One way to circumvent the maximum cookie count limitation is to create a custom subdomain by dedicating a server and unique IP address within your primary domain. For example, if your domain is:
myplace.com
dedicating a subdomain:
home.myplace.com
just for your cookie-controlled home pages gives you the maximum number of cookies possible (20) for your domain.
| NOTE |
If you create a custom subdomain, you must specify the complete domain when you create your cookies. Otherwise, the default behavior is to use the primary domain, which lumps your cookies together with all the others for that domain. |
If you use a custom URL (or, even if you don't and simply use a special subdirectory instead), you can use one additional trick to make remembering the URL even simpler. Most servers are configured to retrieve a file with a particular name with only the domain and path given in the URL. This is called indexing, and it means that if the URL entered into the browser was:
http://home.myplace.com/
The document that is returned is (more than likely):
http://home.myplace.com/index.html
If "index.html" is the dynamic home page construction document, each user that logs in is presented with his or her own page; hence, no two surfers see the same page.
| NOTE |
Not all servers specify index.html as the default index file. Other popular names are: default.htm, index.htm, and index.shtml. Consult your server documentation or check with your provider to find out what the file name is for your system. |
What if There's No Index File? |
If the specified index file isn't found, or if the server isn't configured with default index names, the server will instead return a list of all the files within the specified directory, with each file configured as a hyperlink for opening or downloading. This can be a problem if you don't want to give users a look at the underlying structure of your site. This is an important point to remember: If your server is configured to index, it will do it for any directory. This means that if you keep your graphics in a subdirectory (like images or gfx) and a user figures this out, which is possible by examining the code of your document, he or she can easily try to load: http://home.myplace.com/images/ and will be presented with a list of all your graphics and any subdirectories below that as well. For the Web purist, this is an ugly option, and one that can easily be prevented. One way to keep people from poking where you don't want them to is to place a small HTML file with the appropriate index name in each directory (except those directories where you're already providing such files) that consists of the following HTML code: <HTML><HEAD></HEAD><BODY></BODY></HTML> This effectively blanks the page, preventing the user from seeing what's there. However, this still indicates to a savvy user that the path he or she entered does exist; some people are just too curious, so a more drastic measure would be to have the file redirect the user back to your home page. You can do this by using the redirection techniques from chapter 1, "Browser Identification." This way, if they bounce to a subdirectory you don't want them in, you kick them back to where you do want them. |
Understanding "Cookie Stacking" Each individual cookie has a limit of its own. The cookie can't exceed 4K (4096 bytes) in size, including the name and the other information combined. This can be used to your advantage by squeezing more than one piece of data, or more than one record field, into the cookie. Just be careful not to exceed the 4096-byte barrier, as any data beyond that point will be truncated.
Overcoming Cookie Limitations Whenever one of the cookie limitations is hit, whether it's the number of cookies/domain or number of cookies total, the oldest cookies in the cookie file are deleted as needed to make space for new cookies. Therefore, the "fresher" your cookies are, the less chance they have of being thrown away.
One easy way to ensure freshness is to reset your cookies each time the user visits his or her home page.
With the limitations and workarounds covered thus far in mind, it's time to start designing the "virtual home page." The first step is to get a general idea of what the page will look like, and the easiest way to do that is to write out the page in straight HTML first, then convert it to JavaScript.
Listing 5.1 shows the HTML that creates the simple home page shown in figure 5.1.
Listing 5.1 A Simple Home Page
<HTML> <HEAD> <TITLE>Welcome to Scotty's Place</TITLE> </HEAD> <BODY BGCOLOR=#ffffff> <CENTER> <H1>Welcome to Scotty's Place</H1> </CENTER> <HR> <H2>Favorite Hang-outs:</H2> <UL> <LI><A HREF="http://www.microsoft.com/">Microsoft</A></LI> <LI><A HREF="http://home.netscape.com/">Netscape</A></LI> <LI><A HREF="http://www.cnet.com/">C|Net Central</A></LI> <LI><A HREF="http://www.shareware.com/">Shareware.com</A></LI> </UL> <HR> <A HREF="mailto:sjwalter@visi.com">Send Scotty email</A> </BODY> </HTML>
Looking at the HTML, you'll see that there are several different places for customization:
From this list, you can generate an HTML table/form structure that retrieves the data from the user and saves it as cookie information. The trick is that this table needs to be in the same physical file as the user's actual home page. In other words, the virtual home page document does double duty:
This requires a little dynamic program control, and is best handled by structuring your page so that virtually all of the HTML is written by JavaScript. Listing 5.2 demonstrates the basic structure of the page. Note that listing 5.2 uses the GetCookie() function that was introduced in chapter 4, "Saving Configurations with Cookies."
Listing 5.2 Using JavaScript to Conditionally Display a Page
<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
<!--
...
if (GetCookie("Title") != null) {
HomePage();
} else {
ConfigurationPage();
}
// -->
</SCRIPT>
</HEAD>
</HTML>
The HomePage() and ConfigurationPage() functions do the dirty work of formatting the HTML code for the two possible HTML "documents" this page will create. Because the basic structure of the home page has already been presented (back in listing 5.1), the HomePage() function will be looked at first. This also helps to define what the various cookies are going to be called, which is necessary information when coding the ConfigurationPage() function.
The HomePage() Function The HomePage() function, as shown in listing 5.3, pulls the various information from the cookies stored with the document and translates the data into a personal home page.
Listing 5.3 The HomePage() Function
function HomePage() {
var tStr = "<HEAD>\n" +
GetCookie("Title") + "</TITLE>" +
"</HEAD>" +
"<BODY>" +
"<H1>" + GetCookie("Title") + "</H1>" +
"<HR><UL>";
for(var i=1; i<=3; i++) {
tStr += "<LI>" + '<A HREF="' +
GetCookie("URL" + i) + '">' +
GetCookie("Link" + i) + '</A></LI>';
}
tStr += "</UL>" +
"<HR>" +
'<A HREF="mailto:' + GetCookie("Email") +
'">Send me email</A>';
document.write(tStr);
document.write("</BODY></HTML>");
}
| NOTE |
One thing to keep in mind when building dynamic HTML like this: If you have any attributes within your tags that have "quoted" data (the value of the attribute being enclosed in quotation marks), you should probably use single quotes (') around the JavaScript string and double quotes (") around the value data. |
The ConfigurationPage() Function For cookie data to be available to the HomePage() function, you need to have the user enter the information and "configure" the page. This is handled by the ConfigurationPage() function (listing 5.4).
Listing 5.4 The ConfigurationPage() Function
function ConfigurationPage() {
var tStr = '<FORM>'
+ ' Title <INPUT TYPE=TEXT NAME="Title" SIZE=40>'
+ ' <P>'
+ ' Email <INPUT TYPE=TEXT NAME="Email" SIZE=40>'
+ ' <P>';
for(var i=1; i<=3; i++) {
tStr += 'Link #' + i +
'<INPUT TYPE=TEXT NAME="Link' + i +
'" SIZE=30><BR>' +
'URL <INPUT TYPE=TEXT NAME="URL' + i +
'" SIZE=40><P>';
}
tStr += '<INPUT TYPE=BUTTON VALUE="Configure"' +
'ONCLICK="Configure(this.form)">' +
'<INPUT TYPE=RESET VALUE="Reset">' +
'</FORM>';
document.write("<HTML><HEAD>" +
"<TITLE>Configuration</TITLE>" +
"<HEAD><BODY>");
document.write("<H2>Configure your page</H2>");
document.write(tStr);
document.write("</BODY></HTML>");
}
All this function really does is build (through JavaScript) a document that contains an HTML form with all the fields necessary to create the appropriate cookies. Because this information isn't being sent to the server, you don't need to specify an ACTION attribute or a SUBMIT button; however, you do need to utilize the onClick event of a button on the form to fire another JavaScript function that actually sets the cookie data. This function, Configure(), is shown in listing 5.5.
Listing 5.5 The Configure() function
function Configure(form) {
SetCookie("Title", form.Title.value);
SetCookie("Email", form.Email.value);
for(var i=1; i<=3; i++) {
var tTmp = eval("form.Link" + i + ".value")
+ "*"
+ eval("form.URL" + i + ".value");
SetCookie("Link" + i, tTmp);
}
window.location.href = "index.htm";
}
You can give your virtual home page builder a little personality (or attitude, if you will) by using JavaScript to dynamically change the page each time the user drops by. One way to accomplish this is to take advantage of the JavaScript Date object to dynamically display a message to the user depending on the time of day he or she stops by. Listing 5.6 demonstrates this simple enhancement.
Listing 5.6 A Time-Varying Display
d = new Date();
hour = d.getHours();
if(hour < 5) {
document.write("Doing a little late-night surfing, eh?");
} else if(hour < 6) {
document.write("Up early, I see! Do you have your coffee?");
} else if(hour < 12) {
document.write("Good morning!");
} else if(hour < 18) {
document.write("Good afternoon!");
} else {
document.write("Good evening!");
}
The cookie-based home page has the beauty of not requiring any fancy server-side manipulation because the entire process can be done within the browser through JavaScript. However, as you've seen, the limitations of the cookie specification, coupled with the paranoia about cookies that has spread through the Web community recently, make such an implementation only practical for a couple of reasons:
If you want to make your home-page service available to the general public, a means is needed to store more information than can be kept in cookies and store it more permanently. This means Perl and a little server-side database work.
The Perl version of the page, available on the CD-ROM, isn't much different from the JavaScript version, except that instead of storing everything as a collection of cookies, it only stores one cookie: a unique file name that corresponds with a database file on the server containing the user's configuration information.
The virtual home page designs presented here are simple, yet they should give you some ideas as to how to easily expand on their structure.
Here are some hints:
Extend the database to allow the user to specify a background image, perhaps from a collection of textures you keep on your site.
Let the user embed graphics within the page from a collection of images you provide.
Add a "quote of the day" or similar option, where you pull data at the time the user loads the page from another database and add it to the page.
Add the user's birthdate to the database, and have his or her home page wish him or her "Happy Birthday."
Extend the database to hold important dates and reminders.
This chapter took the tools from chapter 4, "Saving Configurations with Cookies," and extended them to create a "no-memory required" home page for your visitors.
For additional tips and tricks using these techniques, check out: