Category: Technology

Categories
JavaScript

Implement a DHTML Mouseover effect with DOM

Originally published in WebBuilder magazine. Found courtesy Wayback Machine.

The DOM, or Document Object Model, is a specification recommended by the World Wide Web Consortium (W3C) primarily to help eliminate cross-browser dynamic HTML differences. It is implemented with Microsoft’s Internet Explorer (IE) 5.x, and will be implemented with Netscape’s Navigator 5.x when it is released. You probably haven’t seen that many demonstrations of the DOM and its impact on DHTML implementations, and the ones you have seen probably have been fairly complicated. At times you might even think it would be less complicated and would require a lot less code to implement the DHTML using the technologies supported in the 4.x browsers and just deal with the cross-browser problems.

However, you will find that in the long run, the DOM, in addition to XML (Extensible Markup Language), HTML 4.0, and CSS (Cascading Style Sheets), will simplify your development efforts once you have grown accustomed to the technology. In fact, using the DOM can actually make your coding a whole lot easier and cut down on the number of lines of code you need, depending on what you hope to accomplish.

This article will show you how to create a text-based menu mouseover effect, complete with menu tips that will work with IE 5.x and with the August, 1999 M9 build of Gecko available at Mozilla.org (as tested in a Windows environment). Before learning how to use the DOM specification to create a mouseover effect, you might find it useful to get a little history on mouseovers as they are implemented without using the DOM. This next section will highlight why the DOM is an improvement over the existing implementations of DHTML.

Pre-DOM Mouseover Effects
One of the first implementations of “dynamic” HTML occurred when Netscape exposed images for access from an images array from the HTML document object, and then allowed you to modify the source of the image through the src attribute. For instance, this line of code uses JavaScript to replace the existing source of a displayed image with a new image source:


document.images[0].src = "somenew.gif";

A popular use of this dynamic HTML technique was to implement the mouseover effect. The mouseover effect gives a visual cue to the user that the mouse’s cursor is over a certain element in a Web page. The cue remains visible until the cursor moves away from the element. The mouseover effect has long been considered one of the classic implementations of dynamic Web page effects.

Most commonly, you use mouseover effects to highlight menu items. A problem with using the image changing approach for this purpose is that you have to use graphics for the menu, adding to the overall page download times, and the effect won’t work with anything but images. If you wanted to provide a help message for the menu item, you would need to include this message as a part of the image or use some other technique such as Java applets.

These limitations were resolved when CSS positioning and styles, and exposure of the browser document object model, were released under the term of “Dynamic HTML” (DHTML) in Microsoft’s Internet Explorer 4.x and Netscape Navigator 4.x. With the introduction of DHTML, changing the image source wasn’t the only approach you could take to generate a mouseover effect. You could use dynamic positioning, including hiding and showing elements to display the associated menu item text.

This example shows a menu item with a hidden menu text tip. By capturing the onMouseOver and onMouseOut event handlers, you change the style of the menu text to show the tip when the mouse is over the menu item; otherwise you return the text to its original appearance to hide the tip:


<DIV id="one" style="width: 150; z-index: 1" 
   onmouseover="this.style.color='red';onetext.style.visibility='inherit'"
   onmouseout="this.style.color='black';onetext.style.visibility='hidden'">
Menu Item One
</DIV>
<DIV id="onetext" style="visibility: hidden; margin: 20px">
This is the associated text for Menu Item One
</DIV>

However, this approach did not work as intended because the implementation of DHTML included with the 4.x browsers only supported element hiding when the element was positioned. Also, the style setting would not work with Navigator 4.x. Navigator 4.x does not allow you to modify the script of an element’s CSS1 style setting after the element has been rendered (displayed) to the page.

To get around the cross-browser limitations and differences, you could create two different absolutely positioned versions of the elements, and hide one of them. The hidden element would then have the “highlighted” CSS style setting and would be shown when the mouse was over the element and hidden otherwise:


<DIV id="one1" style="z-index: 1"
   onmouseover="switch_on('one')">
Menu Item One
</DIV>
<DIV id="one2" style="color: red;
   font-weight: 700; z-index: 2; visibility:hidden"
   onmouseover="switch_off('one')">
Menu Item One <br>
This is the associated help text to display with menu item one
</DIV>

This approach again worked with IE, but not with Navigator, because Navigator and IE supported different event models and event handlers. To make sure event handling worked with both browsers, and to be consistent, you would use a link to surround the menu item and the mouse events would be captured in the link:


<a href="" onclick="return false" onmouseover="switch_on('one')">

With this workaround, the mouse events are being captured correctly, but there’s still one more problem remaining, which I call the “phantom mouseover effect.” Normally, a user moves the mouse cursor over an element, triggering the process to hide the regular menu item and show the highlighted version. When the user moves the mouse cursor away, the effect is reversed. However, if the person moves the mouse too quickly, the original element gets both the mouseover and mouseout events before the highlighted menu item is even shown. When this happens, the highlighted element stays visible even when the mouse is moved out of the area because it didn’t receive the mouseout event, leaving what is virtually a phantom effect. The user must move the mouse’s cursor over the item again, more slowly, to trigger the regular menu item to appear.

To avoid this phantom effect, you can employ another technique that uses a third, invisible element. In this case, you use a small transparent GIF image and size it to fit over the menu item. The invisible element traps both the mouseover and mouseout events, and invokes the functions to hide the regular and highlighted menu items accordingly. Here is an example of this type of mouseover handling that works with Navigator 4.x and up and IE 4.x and up. First, you create the menu item, its highlighting, and the event capturing blocks:


<!-- menu item one -->
<DIV id="one" style="left: 140; top: 140; z-index: 2">
<a href="" onclick="return false" 
   onmouseover="switch_on('one')"
   onmouseout="switch_off('one')"><img src="blank.gif" 
width=150 height=30 border=0></a>
</DIV>

<DIV id="oneb" style="left: 150; top: 150;
   z-index: 1">
Menu Item One
</DIV>

<DIV id="onec" style="left: 150; top: 150; 
   z-index: 1; visibility:hidden"
   class="highlight">
Menu Item One -
This is the associated help text to display with menu item one
</DIV>

Next, you create the script that processes the menu highlighting:


// set items visibility using 
// specific browser technology
function SetObjVisibility (obj, visi) {
   if (navigator.appName == "Microsoft Internet Explorer")
        document.all(obj).style.visibility=visi;
   else
        document.layers[obj].visibility=visi;
}

// switch highlighting on
function switch_on(theitem) {
   SetObjVisibility(theitem+"b", "hidden");
   SetObjVisibility(theitem+"c","inherit");
}

// switch highlighting off
function switch_off(theitem) {
   SetObjVisibility(theitem+"c", "hidden");
   SetObjVisibility(theitem+"b","inherit");
}

To overcome cross-browser document object model differences, you use an eval function to evaluate and invoke the visibility setting for the element being hidden or displayed. This page will work with Navigator 4.x and up and IE 4.x and up. However, the workarounds to the cross-browser problems make the code much larger and more complex than you’d want for such a simple effect. Instead, you should consider using the DOM to create a simple mouseover menu effect.

Enter the DOM
DOM Level 1 is the most recent recommended specification for DOM from the W3C. The DOM supports a browser-neutral specification that, when implemented within a browser, lets you dynamically access the elements within the Web page, using an approach that will work consistently across browsers and across platforms.

Without getting into too much detail on the DOM, the specification groups the elements of a Web page into a hierarchy, and you can obtain a reference to an element by first accessing its parent and then accessing the element from the parent’s element list. For instance, an HTML table would contain rows, the rows would contain cells, and the cells would contain the data that is displayed. To access a specific cell’s data, you would first need to access the table, then the row containing the cell, the cell, and then access the cell’s contents.

Another key aspect to the DOM is that instead of defining every single HTML element within the specification, it defines a fairly generic set of elements and then defines how to work with the elements directly, and as they relate to each other. Additionally, the W3C has provided an ECMAScript binding for the core elements of the DOM, and the HTML-specific API based on the DOM.

The example in this article uses the HTML version of the document object, or HTMLDocument. This version provides a method, “getElementById”, which allows you to access an element within the document by its “ID” attribute. Additionally, Navigator 5.x and IE 5.x both support HTML 4.0 and CSS2 (for the most part), which means both support the onmouseover and onmouseout event handlers within tags such as DIV tags. Also, both browsers expose the style object so you can dynamically modify the CSS style attribute of an element. Here, you define the two menu items and their associated menu tips:


<!-- menu item one -->
<DIV id="one" style="height: 30; width: 140"
   onmouseover="on('one')" onmouseout="off('one')">
Menu Item One
</DIV>

<DIV id="onetext" 
   style="display:none; width: 140; margin: 10px; 
   font-size: 10pt; background-color: white; color: red">
This is the text associated with the first menu item
</DIV>

<!-- menu item two -->

<DIV id="two" id="two" style="height: 30; width: 140"
   onmouseover="on('two')" onmouseout="off('two')">
Menu Item Two
</DIV>
<DIV id="twotext"
   style="display:none; width: 140; margin: 10px; 
   font-size: 10pt; background-color: white; color: red">
This is the text associated with the second menu item
</DIV>

Because you define the menu items as DIV blocks that are not absolutely positioned within the Web page, they will appear in the upper left corner of the document. Also, notice that the menu tips aren’t hidden with the visibility property; you remove them out of the context of the document with the display CSS attribute set to “none”.

Next, you create the script that processes the menu highlighting. This script does a couple of things. First, it uses the type attribute for the SCRIPT element to define the language used for the script block.


<SCRIPT type="text/JavaScript">

Then the script creates functions to highlight the menu item (“on”) and turn off highlighting (“off”). The functions themselves access the menu item and tip by using the DOM method getElementById. This method returns a reference to the element you want to modify:


// get specific div item, identified by node index
var itm = document.getElementById(val);
var txt = document.getElementById(val+"text");

The functions turn the display for the menu tip on or off, depending on whether the mouse is over the menu or has moved away from the menu item. Because you use display instead of visible, the other elements of the page are moved to accommodate the newly displayed item. Visible hides an element but leaves the “box” that the element occupies within the document flow; display set to “none” removes the element completely from the page flow:


// turn on menu tip display
txt.style.display="block";

…

// turn off menu tip display
txt.style.display="none"

In addition to altering the display of the menu tip, you can also change the CSS style on the menu item. For example, you can increase the font weight and modify the font and background color of the element. Notice that no cross-browser code is present in this example. With the 5.x releases of Navigator (as demonstrated in the M9 release of Gecko that you can obtain at Mozilla.org) and IE, both browsers now support exposing CSS attributes through the style object and dynamically modifying these attributes:


// set style properties
itm.style.backgroundColor="green";
itm.style.color="yellow"
itm.style.fontWeight = 700;

By using the DOM (and browsers that support HTML 4.0 and CSS), you can halve the amount of code required to create the mouseover effect, as you can see from the complete example.

Categories
Technology

Creating a Shopping Cart ASP Component

Originally published in ASP Today, October 20, 1999

As soon as HTML forms were added to the HTML specification, and CGI use extended to server-side applications, folks immediately thought of using the Web for online stores – the concept of the shopping cart was born. If you’ve ever done any online shopping, you’ve used a shopping cart.

A shopping cart is basically a small application that maintains a list of the Web shopper’s selections in such a way that they can be viewed and modified at any time. By itself, the cart is a fairly simple application, but folks end up rolling an inventory control system, an order processing system, a customer service system and the overall Web site maintenance into one application with the misnomer “shopping cart”. What should be a small, compact system sprawls into something large and difficult to manage.

The way a cart keeps tracks of items and persists the list of those items, tends to differ from implementation to implementation: they might be tracked for a single session, or persist from session to session. The cart itself can be created on a specific computer or be accessible from many computers. Although a shopping cart application can interface with other applications, like an order system, an inventory system, or general Web maintenance, it does not implement this functionality itself:

This article will look at the creation of a simple ASP-based shopping cart application that uses a Visual Basic shopping cart component – all of which can be found in the download at the end of the article, with a text file telling you what you’ll need and how to use it.

Shopping Cart Implementation Requirements

First and foremost, a shopping cart has to persist from Web page to Web page, so some sort of technique needs to be used to associate an identifier with a shopping cart and then persist that identifier between Web pages. The items contained in the cart do not need to be accessible from all pages, but the cart identifier does. Because of this essential functionality, shopping carts are usually dependent on Web client Cookies to maintain the link between the cart and the shopper.

There are other techniques that can be used to persist information about the cart between pages. Some developers use hidden form fields (containing the shopping cart identifier or possibly a string of the cart’s items), or add shopping cart information to the end of the URL of the new page that is being accessed. Both of these techniques make the cart information available in the new page. To use these techniques in an ASP shopping cart, you could get the hidden form fields from the Forms collection of the Request built-in ASP object; or the appended URL information from the QueryString collection that is, again, part of the Request object.

If a store chooses to support a shopping cart for a session only (carrying information from the user’s initial store access until they log out, close their browser or disconnect from the Internet), then either hidden form fields or query string method will work fine. However, if cart needs to persist beyond the session, then Cookies are the way forward. Using Cookies, the Web developer can persist the shopping cart for the session or for a specified period of time.

Using Cookies alone, the shopping cart and its contents are maintained solely on the client, so the cart’s contents can be accessed quickly. There is, unfortunately, a major limitation with this approach – Cookies can only hold so many items, usually not many more than 50 – 75. Should the cart need to hold more than this, then Cookie technology on it’s own simply isn’t a viable approach, because the Cookie string can get too large. Even a couple of items can create a large Cookie string.

There is another problem with Cookie technology: the cart can’t follow the shopper. So if a shopper starts a cart on their laptop then they have to keep it there: they can’t access the same cart from their desktop computer at home, or a computer at work, because Cookies don’t travel. The shopper could export the cookies to all of their computers if the browser they’re using supports this technology, but most folks don’t consider exporting cookies and many aren’t even aware of this capability.

The solution, then is to bring the shopping cart to the computer and have it create whatever Cookies it needs to be supported in the new environment.

The Ideal Shopping Cart

The ideal Shopping cart that we could implement using ASP and Visual Basic, for the purposes of this article, will allow:

  • An item to be added to a shopping cart at the touch of a button
  • Shopping cart items to persist for more than one shopping session
  • Some indication that there are items in the shopping cart to be displayed, at least on the site’s home page
  • The Web shopper to view the shopping cart contents at any time, and the contents to be displayed whenever an object is added to the cart
  • The store to provide a means to modify the shopping cart items: to remove an item / all items
  • A running total to be maintained each time the shopping cart contents are reviewed
  • The shopping cart to follow the client
  • Support for an indefinite number of items

In order to create the shopping cart, we must first create the cart database support and the cart Visual Basic component project.

Setting up the Cart’s Environment

Instead of implementing all the aspects of the shopping cart within ASP script, we’ll implement the business logic within a Visual Basic component, use stored procedures for database access, and integrate the shopping cart into the ASP infrastructure within the script. Using this separation of functionality will isolate the data access and database structures from the business logic, and isolate the business logic from the implementation environment.

The tables to support the shopping cart are simplified to include only that information necessary to implement the cart: CART , CARTITEM , CUSTOMER , and CUSTOMERCART , and WIDGET . The WIDGET table represents the product table for this example. The table CARTITEM is dependent on both CART and WIDGET , and the CUSTOMERCART is dependent on both CUSTOMER and CART , so foreign key relationships exist between these tables.

The SQL to create the tables within a SQL Server 7.0 database, and the associated indexes and foreign keys are included with the download example code attached to this article.

In addition to the tables, several stored procedures are used to manage data access. Each of these procedures will be described as they are accessed by specific business routines in the sections ahead; but before we can add the methods to implement the business logic, we’ll need to create the Visual Basic project.

Creating the Cart Project

The shopping cart component is created as a new, ActiveX DLL Visual Basic project named, appropriately enough, shopcart . References to the Microsoft ActiveX Data Objects (ADO 2.1 for this example) Library and the Microsoft Transaction Server (MTS) Type Library are added to the project. We’re adding in support for MTS so the component will be able to access the ObjectControl interface, and we’re adding in support for ObjectControl in order to enable just-in-time activation for the shopping cart component.

Some basic component functionality is added, including the use of Option Explicit at the top of the class file, and the ObjectControl implementation. The only functionality added to the ObjectControl methods (Activate, Deactivate, CanBePooled) at this time is to define a member that holds the Database connection string.

Option Explicit

' The connection string is available to all shopping cart methods
Private m_connString As String

'Implementation of ObjectControl interface
Implements ObjectControl

' ObjectControl Methods
Private Sub ObjectControl_Activate()
    m_connString = "driver=
{SQLServer};server=FLAME;database=writing;uid=sa;pwd="

End Sub

Private Function ObjectControl_CanBePooled() As Boolean
    ObjectControl_CanBePooled = False
End Function

Private Sub ObjectControl_Deactivate()
 ' no activity
End Sub

Because there is a lot to get through in this article, I’m not going to go into the ObjectControls method (these areas will be covered in another article, coming soon – Ed ). The next thing to add is the functionality specific to our implementation of the shopping cart, starting with the methods to create the shopping cart and to add an item to the cart.

Adding Methods to Create a Cart and Add Items

The first requirement of the shopping cart is that users can add items to it, and implicitly, the ability to create a cart itself. We’ll implement both of these requirements as methods.

A cart can be created either when a shopper first accesses a site, or when the shopper makes an initial move to adding an item to the cart. The cart I’m going to build here will take the second approach, will only be created if none already exists, and will be created through a method called in the page that displays the shopping cart contents.

You can add a new cart through a stored procedure called SP_NEWCART , which adds a new record to the CART table, and returns a unique cart identifier:

CREATE PROCEDURE [SP_NEWCART] 
AS
BEGIN
insert into cart (date_created)
values (getdate())
select max(cart_id) from cart
END

To access this stored procedure, a function named createCart , having no parameters and returning a LONG value, is added to the cart component. The returned value is the new shopping cart identifier returned from SP_NEWCART .

Within createCart , new Command and Recordset objects are created and a connection string is added to the ActiveConnection property of the Command object. In addition, the Command CommandType is set to adCmdStoredProc and the stored procedure name is assigned to the Command object’s CommandText property.

' createCart
' Generate shopping cart ID
' create cart without customer association
'
Function createCart() As Long

  Dim comm As New Command
  Dim rs As New Recordset

  ' open connection, attach to Command object
  comm.ActiveConnection = m_connString
  
  ' set Command object properties
  comm.CommandText = "SP_NEWCART"
  comm.CommandType = adCmdStoredProc
 
  ' execute command and get output value (cartid)
  Set rs = comm.Execute
  
  ' get cartid
  rs.MoveFirst
  createCart = rs(0)

  rs.Close

End Function

When the Command object is executed, a record is returned and assigned to the Recordset object. Only one value is returned with the record, the cart identifier, which is then assigned to the function name and returned to ASP application.

To integrate this new component method and associated functionality into the ASP shopping cart application as a whole, the Cookies collection of the ASP built-in Request object is accessed, and the contents examined for an already identified cart. If one is found then it is used as the cart identifier for displaying cart contents. Otherwise, an instance of the shopping cart component is created and the createCart function is called. The newly returned cart identifier is then assigned to the Cookies collection of the Response built-in ASP object, and the cart identifier is created as a client-side cookie. Doing this persists the cart identifier between pages of the shopping cart application, and even beyond the current shopping session. In the example, the Cookie persists until the date set in the Expires property of the Cookie, which is December 31, 2001 in our code.

cartid = cart.createCart()
Response.Cookies("cartid") = cartid
Response.Cookies("cartid").Expires = "December 31, 2001"

We’ve implemented the functionality to add a new cart, but of course it isn’t very useful unless we can add items to it:

First, a stored procedure is created, SP_ADDITEM , to handle the addition of a new cart item. Within this procedure, a check is made of the table CARTITEM to see if a record already exists for the specific cart and product item. If found, the quantity passed to the stored procedure is added to the quantity for the cart item. If a record is not found, a new entry to CARTITEM is made for the specific cart and product.

CREATE PROCEDURE [SP_ADDITEM]
(@cartid int, @itemid int, @qty int)
 AS
BEGIN
IF (select count(*) from cartitem where cart_id=@cartid and 
      widget_id = @itemid) > 0 
   update cartitem
     set quantity = quantity + @qty where 
      cart_id = @cartid and widget_id = @itemid
ELSE
    insert into cartitem values (@cartid, @itemid, @qty, getdate())
END

The stored procedure SP_ADDITEM is called from within a new method, addItem , and added to the shopping cart component. In this method, the ADO Connection object is used both to connect to the database and invoke the stored procedure.

' addItem
' Adds item to shopping cart
' If more than one item, update quantity in SP
'
Sub addItem(ByVal lCartID As Long, ByVal lItemID As Long)

  Dim conn As New Connection
  
  ' connect to database
  conn.ConnectionString = m_connString
  conn.Open
 
  ' build command string
  Dim strComm As String
  strComm = "SP_ADDITEM " & CStr(lCartID) & "," & CStr(lItemID) & ",1"
                
  ' execute command
  conn.Execute strComm

  conn.Close

End Sub

The cart identifier discussed earlier and the product identifier are passed as parameters to addItem . We already have the cart identifier, and so the product identifier is passed to the shopping cart page from a form on a product page. The value is accessed from the Form collection of the built-in ASP Request object.

Dim itemid
itemid = Request.Form("itemid")

If itemid <> "" Then 
   cart.addItem cartid, itemid
End If

So, at this point we’ve created a cart and added an item to it. The next logical step to take in developing the shopping cart component and application is to provide a technique for displaying the cart contents:

Displaying the Cart Contents

The shopping cart display is the most visual aspect of a shopping cart application, and it is also one of the easiest to implement. Basically, the shopping cart items are accessed and displayed, as rows, usually within an HTML table.

A new stored procedure is created, SP_GETITEMS , which gets information from the CARTITEM and the WIDGET tables. The items that the cart contains are located in CARTITEM , but the information about the item, such as product name, price, and quantity per unit are found inWIDGET , hence the join between both tables. Additionally, a total price is calculated from the quantity of items ordered and the price per item, and this total is added as a “column” to the record being returned.

CREATE PROCEDURE [SP_GETITEMS]
(@cartid int) AS
select widget.widget_id, 
          short_name, 
          qty_unit,
          price,
          quantity,
          price * quantity total
    from cartitem,widget where cart_id = @cartid and 
    widget.widget_id = cartitem.widget_id

A new function is created, getItems , which calls SP_GETITEMS and returns the resulting recordset as a disconnected recordset . By returning the entire recordset to the ASP page, we can use built-in Recordset functionality to access and display the returned records and the individual fields. By using a disconnected recordset, the database connection is released before the recordset is returned to the ASP page, and valuable database resources aren’t being tied up unnecessarily.

' getItems
' return list of items, short decriptions, quantity
' as disconnected recordset
'
Function getItems(ByVal lCartID As Long) As ADODB.Recordset

  Dim conn As New Connection
  Dim rs As New Recordset
  conn.ConnectionString = m_connString

  ' connect to database
  conn.Open
  Set rs.ActiveConnection = conn
  
  ' set and open recordset
  rs.CursorLocation = adUseClient
  rs.Source = "SP_GETITEMS " & CStr(lCartID)
  rs.Open

  ' disconnect recordset
  Set rs.ActiveConnection = Nothing
  conn.Close

  Set getItems = rs.Clone

  rs.Close
End Function

An HTML table is created within the body of the ASP shopping cart page, and table headers are used to provide column labels for the individual recordset fields. Because the shopping cart can be updated — new quantities can be added for an item or an item can be removed – the HTML table displaying the cart items is contained within an HTML form, so the changes can be submitted back to the shopping cart application.

Following the HTML table and form definitions, ASP script is used to access the recordset with the cart items and output the recordset rows as table rows (records) and cells (columns).

Dim total
Do While rs.EOF = False
     total = total + rs(5)
     Response.Write("<TR>")
     Response.Write("<TD align='middle'><input type='hidden' name='itemid' value='" & rs(0) & "' size=10>")
     Response.Write("<strong>" & rs(0) & "</strong></TD>")
     Response.Write("<TD align='left'><strong>" & rs(1) & "</strong></TD>")
     Response.Write("<TD align='middle'><strong>" & rs(2) & "</strong></TD>")
     Response.Write("<TD align='right'><strong>" & FormatNumber(rs(3),2) & "</strong></TD>")
     Response.Write("<TD bgcolor='white' align='middle'><input type='text' name='quantity' value='" & rs(4) & "' size=10></TD>")
     Response.Write("<TD align='right' ><strong>" & FormatNumber(rs(5),2) & "</strong></TD>")
     Response.Write("</TR>")
     rs.MoveNext
Loop  
Response.Write("<TR><TD align=right colspan=6><strong>Cart Subtotal is: $" & FormatNumber(total,2) & "</strong></td></tr>")

Notice in the ASP script that a hidden form field holds the product item identifier for each row, and another form input element holds the quantity of items added to the cart for the item. The hidden field is used to tie a product identifier to quantity, and the quantity field is a text input element, giving the Web shopper to ability to modify the quantity of a specific item in the cart.

Following the ASP script, traditional HTML is again used to provide handling of form submission, including options to submit the shopping cart to the order processing system, return to the main store page, continue shopping, and to update the shopping cart to process a quantity change. Updating quantities is discussed in the next section.

Updating Shopping Cart Contents

Imagine for a moment going into a grocery store and adding several items to your shopping cart. Now imagine not being able to remove an item from the cart once the item is placed there, or being unable to change the quantity of a specific item in the cart. If you couldn’t modify the cart contents at a “real” store you probably wouldn’t return to the store and the same applies to the shopping cart implemented at a virtual store. Shopping carts must provide the capability for Web shoppers to modify their cart contents after the contents have been added.

Modifying cart items includes being able to change the quantity of an item in the cart and to remove an item from the cart altogether — two different functions that really only requires one stored procedure, SP_UPDATEQTY . The quantity being passed is checked within the stored procedure : if the value is zero (0), the cart item is deleted from CARTITEM ; otherwise the value is updated. In addition, the stored procedure checks to see if a row exists for the cart and item in CARTITEM . If it does, the value is updated; otherwise the stored procedure SP_ADDITEM is called to create a new cart item with the new quantity. Another approach to removing the item could be to add a button to delete the item from the cart. This could set the quantity to zero, or even call submit the cart for update immediately – either approach works.

CREATE PROCEDURE [SP_UPDATEQTY]
(@cartid int, @itemid int, @qty int)
 AS
BEGIN
   IF @qty = 0
      delete from cartitem where cart_id = @cartid and widget_id = @itemid
   ELSE IF (select count(*) from cartitem where cart_id = @cartid and 
         widget_id = @itemid) > 0
      update cartitem
      set quantity =  @qty where 
          cart_id = @cartid and widget_id = @itemid
  ELSE
      exec sp_additem @cartid, @itemid, @qty
END

The SP_UPDATEQTY stored procedure is called from a new method added to shopping cart component and called updateItemQty . This method has three parameters, the cart identifier, the product identifier and the quantity. It checks to make sure the quantity isn’t negative, and then builds a call to SP_UPDATEQTY .

' updateItemQty
' Update quantity of item
' return new count of items
'
Sub updateItemQty(ByVal lCartID As Long, _
                        ByVal lItemID As Long, _
                        ByVal lQuantity As Long)
                        
  Dim conn As New Connection
  
  ' quantity cannot be less than zero
  If lQuantity < 0 Then
      Err.Raise 5 ' invalid argument error
  End If
       
  ' connect to database
  conn.ConnectionString = m_connString
  conn.Open
 
  ' build command string
  Dim strComm As String
  strComm = "SP_UPDATEQTY " & CStr(lCartID) & "," & CStr(lItemID) & _
                "," & CStr(lQuantity)
                
  ' execute command
  conn.Execute strComm
  conn.Close

End Sub

The updates to the quantities occur in the same shopping cart display page that receives new product items, so way of determining whether an item is being added or the quantity is being updated needs to be added in. For our example, a hidden field is added to the update quantity form on the shopping cart display page, and to the product form on the product display page. The hidden field has a name of startpos , and the value attached to this field determines what action is taken when the shopping cart page is accessed. If a value of update is accessed, then an update is to be made.

<input type="hidden" name="startpos" value="update">

If a value of additem is found, then the add item functionality is used.

<input type="hidden" name="startpos" value="additem">

With the addition of the new hidden fields, and the update quantity component method, the ASP script in the shopping cart page is amended to allow for adding new items and updated quantities.

Dim action
 action = Request.Form("startpos")
 If action = "additem" Then
    Dim itemid
    itemid = Request.Form("itemid")

    If itemid <> "" Then 
      cart.addItem cartid, itemid
    End If

  ElseIf action = "update" Then
    For i = 1 to Request.Form("quantity").Count
       cart.updateItemQty cartid, Request.Form("itemid")(i), _
				 Request.Form("quantity")(i)
    Next
  End If

We now need to add the functionality that associates the cart with a specific customer, so that the customer can access this cart from any computer, and that empties the cart if the customer decides not to place an order. These are detailed next.

Associating Cart to Customer and Emptying Cart

At this time we have all the functionality necessary to create a cart, add items to the cart, persist the cart beyond a specific session and update the cart contents. However, to make the cart callable, which means a client can access it from any computer, we need to associate the cart to a customer.

A new stored procedure, named SP_CUSTOMERCART is created, which simply updates the cart’s customer identifier field with a specific customer identifier. How the customer identifier is accessed and the login procedure for the customer is outside the scope of the shopping cart application.

CREATE PROCEDURE [SP_CUSTOMERCART]
(@cartid int, @custid int)
 AS
BEGIN
  update cart set customer_id = @custid where 
  cart_id = @cartid
END

The stored procedure is accessed from a new shopping cart component method, addCartToCust, which does a couple of tasks. First, the method checks to see if the customer already has a cart and if so, the contents of the new cart are transferred to the older cart and the new cart is destroyed; otherwise the customer is assigned to the new cart.

' addCartToCust
' associate customer to cart
'  -- shipping cost and tax comes from customer state
'     these values cannot be calculated without customer
'
Function addCartToCust(ByVal lCartID As Long, ByVal lCustomerID As Long) As Long

  Dim lcart As Long
  
  ' check for existing customer cart
  ' if found, merge contents
  lcart = getCartID(lCustomerID)
  
  If lcart > 0 Then   ' existing customer cart found
     Dim rs As New Recordset
     Set rs = getItems(lcart)
     Dim i As Integer
     
     ' transfer new quantities to existing cart items
     For i = 1 To rs.RecordCount
        updateItemQty lcart, rs(0), rs(4)
     Next i
     
     ' destroy 'new' cart, use existing
     If lcart <> lCartID Then
        clearCart (lCartID)
     End If
  ElseIf lcart = 0 Then   ' no existing cart
    lcart = lCartID
    ' connect to data store
    Dim conn As New Connection
    conn.ConnectionString = m_connString
    conn.Open
    
    ' build command string and execute command
    Dim strCmd As String
    strCmd = "SP_CUSTOMERCART " & CStr(lCartID) & "," & CStr(lCustomerID)
    conn.Execute strCmd
    conn.Close
  End If
  
  ' return cart id
  addCartToCust = lcart

End Function

The addCartToCust method itself calls other component methods. The updateItemQty, discussed earlier, is used to transfer the contents of the new cart to the existing cart. In addition, a couple of new methods are created and used: one, getCartID, is used to return a cart identifier given a customer identifier; the other, clearCart, will remove the cart and its contents.

The getCartID uses a stored procedure called SP_GETCARTID to get any cart identifier for a given customer.

CREATE PROCEDURE [SP_GETCARTID]
(@customerid int)
 AS
BEGIN
select cart_id from cart where customer_id = @customerid
END

The method is fairly simple, basically little more than a call to the stored procedure, and validation checks to make sure a value of zero(0) is returned if no cart identifier is found.

'
' getCustomerID
' get customer id given cart id
'
Function getCustomerID(ByVal lCartID As Long) As Long

  Dim conn As New Connection
  Dim rs As New Recordset
  conn.ConnectionString = m_connString

  ' connect to database
  conn.Open
  Set rs.ActiveConnection = conn
  
  ' set and open recordset
  rs.CursorLocation = adUseClient
  rs.Source = "SP_GETCUSTOMERID " & CStr(lCartID)
  rs.Open
  
  ' get cartid
  If rs.RecordCount > 0 Then
    rs.MoveFirst
    If IsNull(rs(0)) Then
       getCustomerID = 0
    Else
       getCustomerID = rs(0)
    End If
  Else
    getCustomerID = 0
  End If
  
  rs.Close
  conn.Close

End Function

The clearCart method calls a stored procedure called SP_CLEARCART that deletes the cart items associated with a cart first, and then deletes the cart.

CREATE PROCEDURE [SP_CLEARCART] 
(@cartid int)
AS
BEGIN
   delete from cartitem where cart_id = @cartid
   delete from cart where cart_id = @cartid

END

The clearCart method itself is literally nothing more than a ASP component wrapper for the stored procedure call.

' clearCart
' Clears cart, removes all items
' disassociates customer from cart
'
Sub clearCart(ByVal lCartID As Long)

  Dim conn As New Connection
  
  ' connect to database
  conn.ConnectionString = m_connString
  conn.Open
  
  ' call stored procedure
  conn.Execute ("SP_CLEARCART " & CStr(lCartID))
  conn.Close

End Sub

Now, the ASP script to add a customer to a cart can be run when the person first logs into the store, or when an order is made – this is up to the individual Web store developer. In the example we’re working with, the cart is added to the customer the first time an item is added to the cart. The script itself is fairly simple.

' create the component instance
Dim cart
Set cart = Server.CreateObject("shopcart.cart1")

Dim cartid
cartid = Request.Cookies("cartid")
If cartid = "" Then
    cartid 0
End If

Dim customerid
customerid = Request.Cookies("customerid")
Dim action

If customerid <> "" Then
	cartid = cart.getCartID(customerID)
End If

action = Request.Form("startpos")
If cartid = 0 AND action <> "" Then
    cartid = cart.createCart()
    Response.Cookies("cartid") = cartid
    Response.Cookies("cartid").Expires = "December 31, 2001"

    If customerid <> "" Then
	cart.addCartToCust cartid, customerid
    End If
End If

In the code, the “action” variable is accessed from the Form collection. If an empty string is returned then we know that the shopping cart is not being called as a result of a quantity update, nor is it being called as a result of adding a new item. The shopping cart page is being called purely to display the cart, as a request from the Web shopper.

At this time, we have a shopping cart component, stored procedures, and supporting ASP pages to create a cart, add items to the cart, modify items in the cart, associate the cart with a customer, and destroy the cart. Are we finished? Not quite yet, we have one more requirement left to implement: we need to show how many items a person has in a cart from the store’s home page.

Displaying Summary Information about the Cart

Displaying information about a cart on the home page of a store is relatively simple. A stored procedure is created to return summary information about the cart such as the quantity of items ordered and the total cost (without shipping and tax). This stored procedure is named SP_GETITEMTOTALS .

CREATE PROCEDURE [SP_GETITEMTOTALS]
(@cartid int)
 AS
BEGIN
   select sum(quantity) items, sum(price * quantity) total from 
   cartitem, widget where 
   cart_id = @cartid and 
   widget.widget_id = cartitem.widget_id
END

This stored procedure is then called from within a method, getItemTotals that has a cart identifier as a parameter and returns a disconnected recordset containing the cart information to the ASP page.

'
' getItemTotals
' Returns count of items currently in basket
'
Function getItemTotals(ByVal lCartID As Long) As ADODB.Recordset

  Dim conn As New Connection
  Dim rs As New Recordset
  
  ' connect to database
  conn.ConnectionString = m_connString
  
  conn.Open
  Set rs.ActiveConnection = conn
  
  ' set and open recordset
  rs.CursorLocation = adUseClient
  rs.Source = "SP_GETITEMTOTALS " & CStr(lCartID)
  rs.Open

  ' disconnect recordset
  Set rs.ActiveConnection = Nothing
  conn.Close

  Set getItemTotals = rs.Clone
  
  rs.Close
End Function

In the ASP page, the disconnected recordset is then used to access the number of items in the cart and the total, which are then displayed to the page.

Dim cart
Set cart = Server.CreateObject("shopcart.cart1")

Dim cartid
cartid = Request.Cookies("cartid")
Dim customerid
customerid = Request.Cookies("customerid")
Dim rs

If customerid <> "" Then   
  Dim firstname
  Dim lastname
  Set rs = cart.getCustomer(customerid)
  If rs.RecordCount > 0 Then
    Response.Write ("Hello " & rs(0) & " " & rs(1))
    Response.Write(" - If this isn't you, please <a href='getnewcust.asp'>Login to your account</a>")
    cartid = cart.getCartID(customerID)
    If cartid = 0 Then
   	cartid = ""
    End If 
   End If
ElseIf cartid = "" AND customerid = "" Then 
  Response.Write("<a href='getcust.htm'>Login to your Account to retrieve an existing cart</a>")
End If

If cartid = "" Then
  	Response.Write("<br>Currently, your shopping cart is empty")
Else
    Set rs = cart.getItemTotals(cartid)
    If rs.RecordCount > 0 Then
       rs.MoveFirst
       Response.Write("<br>Currently you have <strong>" & rs(0) & "</strong> items in your cart ")
       Response.Write("for a total of <strong>$" & FormatNumber(rs(1),2) & "</strong> dollars.")
    End If
 End If

If the cart Cookie is empty (no cart is set on the host computer), a message to this effect is shown in the page; otherwise the summary of the cart contents is printed out. In addition, the name of the person who owns the current cart is displayed, and the Web shopper is given the option of logging into the system.

Information about the customer is returned with a new stored procedure, SP_GETCUSTOMER . The login portion of this shopping cart application is included – as an extra bit of bonus code! – with the sample code attached to this article.

In Summary

Web stores can be complicated applications, but the best approach to create a Web store is to break the store’s functionality into individual pieces, or applications, and implement each of these in turn.

A key aspect to the implementation strategy of the shopping cart is that it’s business logic should be kept as separate as possible from implementation and database details. Implementation details, such as ASP specific functionality, are handled within the ASP scripts, and data access is processed within stored procedures. With this approach, changes to either the implementation or the data schema impact little if at all on the shopping cart component itself.

This article took a look at one specific application of an online store, the shopping cart, and demonstrated how a cart can be implemented without a lot of complicated code using an ASP component written in Visual Basic, some ASP pages, and stored procedures. The sample code for download contains all of the code discussed in the article as well as other functionality to handle pulling the entire application together.

Categories
Technology

Shopping Carts

Recently, someone, I’ll call him Joe, sent me an email and asked a question about maintaining shopping cart items using client-side cookies.

A shopping cart is basically a program that maintains a list of items that a person has ordered, a list that can be viewed and reviewed and usually modified.

Joe had run into a problem in that browsers limit both the size and quantity of cookies that can be set from a Web application, and this limited the number of items that could be added to his company’s online store’s shopping carts. He asked whether there was a client-side Javascript technique he could use that would update a file on the server instead of on the client so that customers could add an unlimited number of items to their carts.

Instead of trying to maintain the company’s shopping cart using cookies, I recommended that Joe check out his Web server’s capabilities, and see what type of server-side scripting and applications his server supported. Then he could use this technology to maintain the shopping cart items. I also recommended that he limit the use of the client-side cookie to setting some form of session ID so that the connection between the cart items and the shopper was maintained.

Shopping Cart Technology

Joe’s email did get me to thinking about how online stores use different techniques to maintain their shopping carts.

For instance, all of the stores I shop at, except one, use some form of a client-side cookie, but each store uses these cookies differently. Additionally, the stores use server-side techniques to support online shopping, though this support can differ considerably between the stores.

Client-side cookies were originally defined by Netscape for use in Navigator, though most browsers support cookies. Cookies are small bits of information stored at the client that can be maintained for the length of a session, a day, a week, or even longer.

The use of client-side cookies is rigidly constrained in order to prevent security violations. You can turn off cookies with your browser, but be aware that cookies do not violate the security of your machine and without the use of cookies your online shopping will be severely curtailed.

This YASD article does a little technology snooping of four online shopping sites and snoops out how each site uses a combination of server-side and client-side processing to maintain its carts.

Covered in this article are the shopping cart techniques used at the following online stores:

  • Amazon.com
  • Beyond.com
  • Catalogcity.com
  • Reel.com

Shop Til You Drop

To understand shopping cart maintenance, its important to understand customer shopping habits. We’ll start this article by looking at some online shopping habits.

First, online shopping has grown enormously in the last few years. Once folks found out that it was safer to send your credit card number over the Net at a secure site then to give it over a wireless phone, much of the hesitation about online shopping vanished.

What are the types of things that people buy online? Books, CDs, and Videos are popular, but so are kitchen utensils, computer hardware and software, photography equipment and film, food gifts, bathroom towels, and even irons.

People shop online because of necessity, convenience, and cost. We purchase books, CDs, and videos online because the online stores have a much larger selection than any local store could possibly have. We know that when we are looking for a book, even an out of print book, we will most likely be able to get the book from one of the online bookstores such as Amazon.

Some businesses we shop at, such as Dell, have no physical store location. This type of business provides service for their customers through mail or phone order, only. Many of us prefer to use online shopping for these types of stores rather than having to call someone up and go through a long list of items or manually fill out an order form, all the while hoping we put down the right item number. It is a whole lot simpler to look at an item and click on an image that says something like “Add to Shopping Cart”. An added benefit to online shopping is that we can review my order before it is sent, and can get a hard copy printout of the order for our records.

Normally, most of us only shop for a few items at a time, but the number of items can become large, especially with online grocery stores — a rising phenomena. However, it isn’t unusual for us to add some items to our shopping cart one day, a couple of more items another day, and so on, until we’re ready to actually place the order. At times we may even forget we have items in a shopping cart, until we add another item to the cart and the previous items show up.

We also change our mind at times, and may need to remove items from the shopping cart, or change the quantity of an item ordered. It’s also handy to have a running total for the order so we can make at least an attempt to stay within our budgets. If the shipping charges are also shown, that’s an added bonus.

Many of us may have more than one computer and may start a shopping session with a laptop and finish it at a desktop computer, though as you will see later in this article, this sometimes isn’t that easy. In addition, the use of both Netscape Navigator and Microsoft’s Internet Explorer on the same machine isn’t all that unusual for heavy Net users, and we may start a shopping cart with one browser and add to the cart from another browser.

Pulling requirements from these patterns of use, we come up with the following:

  • An item can be added to a shopping cart with the touch of a button
  • Shopping cart items need to persist for more than one shopping session
  • Some indication that there are items in the shopping cart should show, at least on the home page for the site
  • The store needs to provide a means to modify the shopping cart items, or to remove an item or all items
  • A running total needs to be maintained each time the shopping cart contents are reviewed
  • Showing standard shipping charges and other costs when the shopping cart is reviewed is an added bonus
  • The shopping cart needs to follow the client
  • Stores need to provide the ability to review an order before placed
  • Stores also need to provide the ability print out the contents of the shopping cart
  • Shopping carts should support an indefinite number of items, or the number of items should be limited by company policy, not Web technology limitations.

A pretty good list of requirements. Now, how do each of the stores measure up?

To determine when cookies are used at each of the sites evaluated, I set my browsers to prompt me when the online store wants to set a cookie. Using this approach I can see what kind of cookies the store uses, and get an idea of the cookie purpose.

Amazon.com

Probably the undisputed king of online bookstores is Amazon.com. This company began as a pure Net-based business, and has shown the world that online commerce not only works, it works very well, thank you.

Amazon has one of the better store interfaces, and some of the best account and order maintenance setups, but does it meet all of our shopping cart requirements? Let’s check it out.

First, all items that Amazon sells can be added to the existing shopping cart with the touch of a button, even items that are on order but not yet in stock. In addition, the shopping cart contents will persist even if you leave the site and return at a later time. In fact, Amazon tells you that the item will remain in the shopping cart for 90 days, if I read this correctly, a feature I found to be very nice.

Bonus technique: Let people know how long the shopping cart items will remain in the cart. The only surprise to pull on a customer is to let them know an item is on sale, or that they are the millionth customer and have won something. Anything else will lose you business.

Amazon also provides a feature to save the item for purchasing at a later time. This removes the item from the cart, but still keeps the item on a list for later purchase.

The shopping cart can be reviewed at any time, and there is an icon on every page that allows you easy access the shopping cart. You can also modify the cart contents by changing the quantity of an item you’re ordering, or removing an item altogether.

Amazon makes use of standard HTML technology, so the shopping cart review page should print out fairly well. Unfortunately, the shopping cart does not display shipping charges and does not display a running total for the items. However, Amazon does show a total, including shipping, that you can review before you place the order. This page can also be printed out.

So far so good. Amazon has met most of our requirements, but the real test of Amazon’s supremacy in shopping cart technology is whether the cart can follow the customer. Unfortunately, the company does not support this capability.

When you access Amazon from a browser at a specific machine for the first time, Amazon sets an ID that is used to track your shopping cart items. Access Amazon from the same browser and the same machine, and you will get the same shopping cart items. However, if you access Amazon from another machine or even another browser, you will not get access to these shopping cart items.

Is it important to maintain shopping cart persistence from browser to browser, machine to machine? You bet it is.

I, as with other folks involved with Web development and authoring, use both Navigator and IE. In addition, there are some sites geared more towards one of these browsers, so most folks who spend a lot of time on the Net have both browsers.

There are times when I am sure I have placed an item in the shopping cart, only to find out I did, but using a different browser or from a different machine. This happens more often than I would like, and is an annoyance every time.

Now the online stores have to ask themselves the question: Are people like myself part of a customer base they want to attract? Think of this: Who is more likely to be purchasing items online than folks who spend a large amount of their time, online. And who is likely to use more than one machine and more than one browser? Folks who spend a lot of time, online.

To summarize, Amazon uses client-side cookies to establish a persistent ID between the customer and the shopping cart. The company also uses this ID to establish a connection from the customer to the customer’s account information. The shopping cart items, however, are maintained on the server, persist for 90 days, and there is no limit to the number of items that can be ordered at Amazon, at least as far as I could see. Where Amazon does not meet the requirements is by not providing a running total on the shopping cart review page, and by not providing a shopping cart that moves with the customer.

Based on the requirements met by Amazon, I give them a score of 8 our of 10, for their support of shopping cart techniques.

Beyond.com

Beyond.com sells computer software and hardware and is a Net-only based company.

Beyond.com maintains a client ID in client-side cookies, which is used to track shopping cart contents for the session, only. Beyond.com does not persist the shopping cart contents outside of a specific browser session. Once you close the browser, the current shopping cart contents are gone.

In addition, it does look as if Beyond.com maintains the shopping cart totally within one client-side cookie, tagged with the name “shopcart”.

By maintaining the shopping cart on the client, Beyond.com has chosen one of the simplest approaches to maintain a shopping cart, and simple can be good. There is little or no burden on the server other than accessing the original item that is added to the cart. There is also less maintenance to this type of system, primarily because the Web developers and administrators do not have to worry about issues of storage of information on the server, or cleaning up shopping carts that become orphaned somehow. Additionally, Beyond.com is taking advantage of a client-side storage technique that is safe and simple to use.

However, there is a limitation with this approach in that the cookie is limited to a size of 4 kilobytes. It may seem that 4K is more than large enough to support a cart, but when you store information for each item such as cart item number, name of product, version, price, store identification number, quantity and price, you can reach an upper limit more quickly then you would think. Additionally, a limit is a limit, and you have to ask yourself if you really want to limit how many items a person can add to their shopping cart.

Most online stores could probably get away with shopping carts that have number of items limitations. After all, it might be a bit unusual to purchase 40 or 50 items from a software company at any one time.

If a store’s customers tend to purchase only a few items at a time, then it might not be cost effective to provide shopping cart technology that provides for virtually unlimited items.

Beyond.com also provides a quick look at the shopping basket from every page of the site. This quick view provides the first few letters of the cart item, the quantity ordered, and a running total for the cart. As much as I appreciate having this information, I found that I would have preferred having just the quantity of items in the shopping cart and the running total: listing all of the items actually became a distraction when I had more than a few.

Beyond.com uses standard HTML and the shopping cart page did print out using the browser’s print capability. In addition, you can review the order, including the shipping charges, before the order is fully placed.

To summarize, I liked Beyond.com’s support for shopping cart status display on the other Web pages. I also liked Beyond.com’s running total. The biggest negative to Beyond.com’s shopping cart was the lack of persistence outside of the browser session. I may not order more than 5 or 10 items at a time, but it isn’t unusual for me to add a couple of items at one time, close down the browser and return at a later time to add more items and finalize the order. In addition, it isn’t impossible for people to accidentally close down their browsers, which means they lose all of the items from their cart and have to start over. Based on the lack of persistence, I would have to give Beyond.com a 6 in shopping cart technology.

Catalogcity.com

CatalogCity is an interesting online business that presents the contents of catalogs from several mail order firms, allowing you to shop for everything from a new jacket to kitchen knives. Once you have placed your order for all of the items you’re interested in, CatalogCity then submits the orders for the individual items to the specific catalog company.

Of all the online shops I have seen, CatalogCity is one of the most clever. It provides both goods and a service, but without the hassle of maintaining inventories and supporting warehouses. I am sure that CatalogCity charges a fee to use their services to the catalog companies listed, but it is most likely more profitable for these companies not to hassle with online ecommerce issues. Even for those companies that have their own site and that use CatalogCity, they will get access to people who are looking to shop, but don’t necessarily know the catalog company’s name or Web site URL.

I do like to see effective and innovative uses of Web commerce. If I have a problem with the site, it is that not all of the catalog companies support online shopping in the catalog through CatalogCity. You can review the catalog and use the phone number provided to place your order. However, it’s just not the same as one button shopping.

CatalogCity uses cookies to set a customer id the first time you access their site. However, after that, all information about the shopping cart is stored on the server. There is no indication in the pages that you have shopping cart items, but you can access the shopping cart from a well placed icon on each site page.

The shopping cart page lists all of the items, provides the ability to change or remove an item, and provides a running total — sans shipping charges. It also provides a hypertext link from the item to the page where the item was originally listed, so you can review the item before making a final purchase.

The technology that CatalogCity uses for their shopping cart is fairly standard, so the cart page should print out easily. In addition, the company does provide the customer the ability to review the order, including shipping charges, before the order is placed.

The CatalogCity shopping cart is the most persistent of all of the shopping carts that I have seen. First, if you access the site but don’t set up an account, the cart will persist from browser session to browser session, but only with the same browser and machine. However, if you create an account with CatalogCity and sign in each time you access the site, the shopping cart will follow you from one browser to another, and from one machine to another. In fact, of all the sites I reviewed for this article, CatalogCity is the only one that provided this functionality.

To summarize the CatalogCity shopping cart technology, the company has provided the best support for shopping cart persistence of all the sites visited. In addition, the company also provides easy access to the cart, and provides a running total on the shopping cart page. CatalogCity also provides you with a change to review and modify your order as well as review the shipping charges before the order is placed. About the only non-positive aspect I found with this site’s shopping cart technology is that the site does not provide information that the shopping cart has items on the first page. If CatalogCity had provided this, I would have given the site a score of 10, but I’ll have to give it a score of 9.

Reel.com

Reel.com is an online video store that sells new, and used, VHS and DVD videos. It has an excellent selection of movies and a nicely organized site.

Reel.com uses cookies to set a user id when you first access the site. When you access a specific item, the site uses ASP pages and ASP (Microsoft’s server-side technology) sets a cookie with a session id when the first ASP page is accessed. After that, no other cookies are set. All shopping cart items are maintained on the server.

ASP or Active Server Pages, was the technology that seemed to be most used at the different online stores. ASP technology originated with the release of Microsoft’s Internet Information Server (IIS), but has since been ported to other Web servers and even to Unix from a company called ChiliSoft.

ASP provides for both server-side scripting as well as server-side programming with ASP components. In addition, ASP provides full support for data access through Microsoft’s Active Data Object technology.

One cookie that is set with ASP is the Session ID. When you access a site for the first time during a browser session, Microsoft tries to set a Session ID, to maintain a connection between your browser and the Web server. Without this, it is very difficult to maintain information about the session, such as shopping cart contents, from Web page to Web page.

Reel.com does not provide a running total for the purchases on the shopping cart page, and does not provide a visual indicator that items are in the shopping cart from any of the pages, except the shopping cart page. The company does provide easy text-based access to the shopping cart from each page and does allow you to change the quantity of an item ordered, as well as remove an item from the cart.

Reel.com provides shipping and full order information for the customer to review and modify before the order is placed, and the order page, as well as the shopping cart, can be printed out.

Reel.com does not provide persistence beyond the session. Once you close the browser, the shopping cart is gone.

To summarize, Reel.com did not score very high by meeting many of the requirements for a shopping cart. It didn’t provide a visual cue about shopping cart contents, at least on the first page of the site, nor did it provide a running total on the shopping cart page. The biggest negative, though, was that the site did not maintain the shopping cart persistently outside of the browser session. Reel.com did provide the ability to review and modify the order before the order was placed, but based on the requirements met, I would have to give Reel.com only a 4 for shopping cart technology.

Summary

Four different online store sites, each using different techniques to support the site’s shopping cart.

All of the sites used cookies to establish a connection between the browser session and the shopping cart. In addition, each site provided shopping cart pages that could be printed out, and provided the ability for the customer to review and modify, or cancel, the order before it was placed.

The highest scorer in my evaluation is CatalogCity, primarily because of their support for persistence across different browsers and machines. This was followed by Amazon, which provided for browser and machine specific persistence.

Both Reel.com and Beyond.com dropped drastically in points because of their lack of shopping cart persistence, in any form. However, Beyond.com did provide feedback as to shopping cart contents, something that CatalogCity and Amazon did not. Beyond.com may want to consider dropping their line item display of the shopping cart as this can be distracting. They were also the only online store maintaining their shopping cart in client-side cookies. While this approach has an advantage of being the quickest technique to displaying the shopping cart contents when the customer wants to review the shopping cart, and is the simplest technique to use, I still don’t see this approach as the way to go for online shopping.

If we could take CatalogCity’s persistence and add to it a running total with estimated shipping charges, and provided feedback on the cart contents in at least the home page of the site, we would have, in my opinion, the perfect shopping cart.

The next article in the Technology Snoop series will be on order processing and order status maintenance. In this you’ll see that Amazon shines. You’ll also read about how not to win customers and to lose the ones you have when I add some new online stores to the review.

Categories
Web Writing

Dynamic Web Publishing Unleashed: Chapter 37 – the Future of Web Publishing

Recovered from the Wayback Machine.

IN THIS CHAPTER

  • The Chaos of Change
  • The Current Technology Platform
  • A Summary Review of the Technologies Covered in the Book–Where Will They Be in a Year?
  • Client Scripting and CSS1 Positioning

With an industry that seems to go through a new revolutionary change at least four times a year, it’s hard to predict where Web publishing will be in four months, much less the next couple of years. However, taking a look at existing technologies and their state and at some new technologies can give us a peek through the door to the future, even though the crack we are peeking through might be pretty small.

First, many of the technologies covered in this book existed two years ago and will continue to be around two years from now. That means Java, which was introduced in 1995, HTML, the scripting techniques, and the basic Web page, which will continue to consist mainly of text and an occasional image. It’s hard to say if some new and incredibly different Web page development technique or tool will appear in the next two years, but regardless, people will also continue to use what is available now. In fact, the technologies introduced this year, such as Dynamic HTML and CSS1, will begin to become more familiar in 1998, and only begin to become mainstream technology in mid- to late 1998.

Web servers don’t seem to increase in technical capability exponentially the way Web page technology does. The real key to server technology is fast, reliable, and secure Web content access. The servers will become faster, hopefully more reliable, and the security should grow to meet the increasing demands placed on these servers to support commercial transactions. Additionally, there are new methods–particularly in the realm of commerce–that will work with existing server technology. Those are discussed in this chapter.

There are new technologies that have barely begun being explored this year. Channels and push technology started out with a bang and nearly ended with a whimper. Web consumers just didn’t buy into the new technology. However, with the built-in channel capability Netscape Navigator and Microsoft’s Internet Explorer have now, and with simpler channel development processes, channels can be considered down, but not out.

The real key to the future rests with standards as much as with implementation. The Document Object Model (DOM) working group of the W3C should present a first working draft of DOM by the end of 1997. DOM covers which HTML elements are exposed, and to an extent, in what way these same elements are exposed, what standard properties and events are, and how these elements relate to each other. If HTML doesn’t meet your needs, just wait–XML describes how to extend any markup language, to create an element such as <BUTCHER> or <BAKER> or, yes, even <CANDLESTICK_MAKER>. This chapter closes with a review of the new technologies currently under review and design.

The Chaos of Change

Sometimes you might feel you have to spend 24 hours a day just to keep up with the technology being released. Needless to say, this is both frustrating and discouraging, all at the same time.

Web development does seem, most of the time, as if it undergoes a revolution in technology every three months; many times one specific aspect of the technology undergoes a change only about once per year. However, preceding the release of the changed technology is a period when the technology is being reviewed, or the product is being beta-tested, or some form of pre-release activity is occurring. Then, the release of the standard or technology or product occurs, and there is a period of comparing it with its older version, or with other products. Then, you have to spend some time learning how the new technology works, how to migrate older pages or applications, or checking to see if existing pages or applications break with the new release. Finally, just when you think you are starting to become comfortable with the new or modified technology, the company or organization announces the new release of whatever the product or standard is.

Consider also that Web development is made up of several different technologies, including browsers, standards, embedded object technology, and server technology. Putting all of these aspects in one category–“Web Development”–and considering the multiple-phase delivery of most Web technology, provides what seems to be continuous change.

As an example, in 1997 it probably seemed as if a new browser were being released every quarter. Well, what actually happened is that there were minor bug fix releases of Netscape Navigator 3.x and Internet Explorer 3.x in the year’s beginning, and Netscape also released several different beta versions of Navigator 4.0 before it actually released Navigator 4.0. After the release, there have been several enhancement and bug fix releases of Navigator 4.0.

Microsoft also released two major beta releases of Internet Explorer and released the final version about the time this book went to editing. There will likely be enhancement and bug fix releases for IE 4.0 before the year is out.

Add the international releases with these other releases, and you have a browser release on the average of about every three weeks, not months.

Also consider that browser manufacturers themselves are at the mercy of the release of new standards or new versions of existing standards. The year 1997 saw the beginning of the DOM effort, a new version of the HTML specification, HTML 4.0, the rise in interest in XML, the passage of the ECMA standard for scripting, ECMAScript, and the recommendation of CSS1 for Web page presentation. And these are only some of the standards that impact browsers.

So, how do the browser manufacturers cope with the changing standards? The same way you can cope with all of the other changing technology: First, you define your Web development and Web client platforms. You determine what technologies make up each, including versions, and concentrate on these technologies, complete the effort you determine to complete with the defined platform, and then, and only then, begin to plan your next Web platforms.

The Current Technology Platform

For many companies and individual users, the current technology platform consists of Netscape Navigator 3.x or Internet Explorer 3.x for the browser, Apache 1.2, Netscape Enterprise Server 2.0 or 3.0, O’Reilly’s WebSite Pro, or Microsoft’s Internet Information Server 2.0 or 3.0.

Most Web pages contain a combination of text and images, and most of the images are static. Many sites use some form of scripting for page interaction, most likely a form of JavaScript. HTML tables are used to handle the layout of HTML elements, as shown in Figure 37.1.

As you can see from the figure, you can actually create a fairly organized page using HTML tables. The page also uses the font element to color the sidebar text white; the color attributes of the table header and contents are used to set the header to red and the contents to yellow.

Animation in a page occurs through the use of Java applets, animated GIFs, Netscape style plug-ins, or ActiveX controls.

The version of Java used with most applets is based on the first release of the JDK–JDK 1.0.

Server-side applications are used to create dynamic Web pages, to present database information, or to process information returned from the Web page reader.

A Summary Review of the Technologies Covered in the Book–Where Will They Be in a Year?

A good rule of thumb when working with content for multiple versions of a tool is to support the currently released product in addition to one previous release. Based on this, you can count on supporting pages that work with Netscape Navigator 3.x and 4.x, and Internet Explorer 3.x and 4.x. As both browser companies begin the rounds of creating version 5.0 of their respective products, the business world will be cautiously upgrading pages to work with the new 4.0 technologies, particularly CSS1, HTML 4.0, and Dynamic HTML. By the time they have made the move to 4.0 technology, the 5.0 release of the browsers should be close to hitting the street.

The browser companies themselves probably follow a similar reasoning in that they support a specific number of versions of a standard, such as HTML, before they begin to drop deprecated content from earlier releases of HTML.

Standards organizations rarely release more than one recommended version of a standard each year. Sometimes they might go longer than a year before a new release, rarely less than a year.

Based on this, the technology you read about in this book should be viable for two years after publication of the book, which takes the Web into the year 2000.

The following sections look at each of the discussed technologies, with an eye on where each is likely to be on the eve of 2000.

HTML 4.0, CSS1

To start with the basics, the foundation of Web publishing is HTML, and this technology was explored in the first part of the book. Additionally, the first part of the book also looked at Cascading Style Sheets (CSS1) and Dynamic HTML. Dynamic HTML’s future is covered in the next section.

As this book goes to press, HTML 4.0 is the version of HTML currently under draft review. This version provides for increased form and table support, deprecates several existing elements, and adds a few new element types and several new attributes, such as intrinsic events.

HTML 4.0 should become a recommended specification at the end of 1997. Currently, Microsoft has incorporated the HTML 4.0 draft specifications into the first release of IE 4.0, and Netscape has promised to adhere to the standard after it becomes a recommendation. Based on this, any changes to the HTML 4.0 draft will probably result in a minor revision release for IE 4.0. However, the HTML 4.0 changes for Netscape Navigator will probably be extensive enough for the company to incorporate these changes in the next release of Navigator, version 5.0. Following the Navigator 4.0 release schedule, you should begin to see the early beta releases of Navigator 5.0 in the spring of 1998.

No new activity is occurring with the CSS1 standard at this time, at least not in its impact on Web page presentation. Additional style sheet specifications are underway for speech synthesizers (ACSS, which is Aural Cascading Style Sheets), and a printing extension is underway for CSS, allowing for accurate page printing. This is in addition to the CSS-P, or Cascading Style Sheet Positioning.

At this time, tools that process, generate, or incorporate CSS1 in some form include HoTMetaL Pro 4.0 from SoftQuad (http://www.softquad.com), Microsoft’s FrontPage 98, Xanthus Internet Writer (http://www.xanthus.se/), Symposia Doc+ 3.0 from GRIF (http://www.grif.fr/prod/symposia/docplus.html), PageSpinner for the Mac (http://www.algonet.se/~optima/pagespinner.html), and others.

In the next year or two, Web pages will begin to incorporate CSS1 and HTML 4.0, though Netscape Navigator 3.x has a base of users wide enough to prevent most companies from using only CSS1 and HTML 4.0 to create Web pages. However, both of the major browser vendors have promised support of these standards, and many of the Web generation’s tools will integrate them into the new versions of their tools. As these new tools are appearing as beta releases now, they should all be released as products in 1998. By the year 1999, most companies that want to control the presentation of their Web pages should be using at least some form of CSS1, and begin the process of removing deprecated HTML elements from their pages.

You can keep up with the standards for HTML at http://www.w3.org/TR/WD-html40/. The standard for CSS1 can be found at http://www.w3.org/Style/.

Dynamic HTML and DOM

In 1997, with the release of version 4 of their browsers, both Netscape and Microsoft provided support for the first time for Dynamic HTML. Dynamic HTML is the dynamic modification and positioning of HTML elements after a Web page loads.

Dynamic HTML is a great concept and badly needed for Web development. With this new technology you can layer HTML elements, hide them, change their colors, their sizes, even change the elements’ contents. That’s the good news. The bad news is that Netscape and Microsoft have implemented different versions of Dynamic HTML–differences that are a little awkward to work with at best, and conflicting at worst.

Neither Netscape nor Microsoft has implemented broken versions of Dynamic HTML. When Netscape published Navigator 3.0 and exposed HTML images to scripting access, there was a great deal of discussion about Microsoft’s “broken” implementation of JavaScript 1.1, the version of JavaScript also published with Navigator 3.0. However, Internet Explorer 3.x was not broken, but the browser did not implement the same scripting object model as Navigator 3.x. Now, with IE 4.0 and Navigator 4.x, the scripting object models are even more disparate, making it difficult to create Dynamic HTML effects that work equally well with both browsers.

The solution to this problem could be found with the Document Object Model standardization effort currently underway with the W3C.

According to the W3C, the DOM defines an interface that exposes content, structure, and document style to processing, regardless of either the language used or the platform on which the DOM application resides. The functionality of Internet Explorer 3.0 and Netscape Navigator 3.0 is defined by the W3C to be level “zero” of the standard. You might assume it is that functionality that both of these browsers support, which means they would not include images.

At this time, the DOM working group has produced a requirements document, which includes items such as those in the following list:

  • All document content, elements, and element attributes are programmatically accessible and can be manipulated. This means that you can use script to alter the color of header text, or dynamically alter the margins of the document.
  • All document content can be queried, with built-in functions such as get first or get next.
  • Elements can be removed or added dynamically.
  • All elements can generate events, and user interactions can be trapped and handled within the event model.
  • Style sheets can be dynamically added or removed from a page, and style sheet rules can be added, deleted, or modified.

This list is just a sampling of the requirements for the DOM specification, but it is enough to see that when the DOM specification becomes a recommendation, the days of the static and unchanging Web page will soon be over.

To see more about DOM, check out the DOM working page at http://www.w3.org/ MarkUp/DOM/.

Client Scripting and CSS1 Positioning

Excluding the objects exposed to scripting access as members of each browser’s scripting object model, there aren’t that many differences between Netscape’s implementation of JavaScript and Microsoft’s implementation of JavaScript.

Scripting will continue to be used in the years to come, and, hopefully, the language will not get too complicated, or the ease of use of scripting languages will begin to diminish.

Again, the major impact on scripting occurs with the elements that become exposed by the DOM effort. However, this is not a guarantee that the same script block written for Netscape’s Navigator will work with Microsoft’s Internet Explorer.

Consider each browser’s implementation of dynamic CSS1 positioning. First, both companies support CSS1 positioning, a draft recommendation actually created by both companies. This standard provides style sheet attributes that control an element’s width, height, z-order (the element’s position in the stack if elements are layered), the location of the left side and top side of the element. The standard also provides an attribute to control the visibility of the object and the clipping area.

Figure 37.2 shows how well CSS1 positioning works by showing a Web page using this technology, opened in both IE 4.0 and Navigator 4.0. Note how the text aligns directly on top of the image (yes, the text and images are separate elements), and that the images are aligned in a vertical line along the left side of the page, without using an HTML table for layout control.

The example in Figure 37.2 is discussed in Chapter 8, “Advanced Layout and Positioning with Style Sheets,” and is located in the file images3.htm at this book’s Companion Web Site.

Using CSS1 positioning to control the layout of text and images.

If statically positioning elements using CSS1 positioning works equally well with both browsers, dynamic positioning does not. Both browsers create the same effects but use different techniques. Considering that standards usually define an effect or behavior but don’t necessarily define a specific technique, you probably won’t be seeing consistent scripting of HTML elements in the next couple of years.

Java

As this is being written, Sun is on the verge of releasing JDK 1.2, Netscape just created a minor release to cover most of the classes released with the JDK 1.1, and Microsoft also supports JDK 1.1 in its release of IE 4.0.

The use of JavaBeans–Java components that can be packaged, distributed, and used and reused in applications–is among the technologies supported with JDK 1.1. It’s a very good idea and one that has already achieved popularity among Java developers.

However, not all is positive in Java’s future, particularly when used with browsers. The browser companies are usually one version release behind the current Java class releases. That is not a problem. What is a problem is a situation that may make creating cross-browser applets virtually impossible.

The difficulties with the original release of Java had to do with the Advanced Windowing Toolkit or AWT classes. For the most part, interface development in Java was difficult and lacked sophistication. To resolve this, both Microsoft and Netscape began work with interface classes, called Application Framework Classes (AFC) by Microsoft and Interface Framework Classes (IFC) by Netscape.

Netscape joined Sun and combined Sun’s current efforts with its own IFC library to create the basis for the Java Framework Classes (JFC), due to be released with JDK 1.2. However, Microsoft had also spent considerable time with its own framework classes. At this time, the end result is Netscape and Sun supporting one set of classes and Microsoft supporting another.

To add to the problem, Sun also submitted Java to ISO (the International Standards Organization), to become a standardized language. They also asked to be designated a Publicly Available Submitter (PAS), or the group responsible for developing and maintaining the specification. At this time, the ISO working group, JTC 1, has voted against the Sun recommendation, with comments. Sun’s response, in effect, is that they will pull the language from ISO and treat it as a de jure standard, meaning that the company will retain control.

This is not a situation that is guaranteed to increase business confidence in the language. Add this to the difficulty of creating applets using any kind of framework, having the applet work with both IE and Navigator, and the increased sophistication of Dynamic HTML, and you may be in for a future decline of Java use for applets.

ActiveX

The new and exciting technology addition to ActiveX is DirectAnimation, DirectX technology extended for use with Java applets, controls, or scripting.

Being able to create ActiveX controls fairly easily using a variety of tools should lead to an increased popularity of these controls with companies whose intranets use Internet Explorer. The downside with the technology is that it is proprietary.

However, Microsoft also released several new filters that were originally ActiveX controls, but then were built in as style attributes. These controls can change the transparency of a Web page element, have a line of text become wavy, or add pinlights to a page. This technology is so fun and simple to use that the demand may likely be to add these to the DOM once it is released.

With this technology you can create rollover effects for menu images without the extra download of the rollover effect image.

CGI and Server-Side Applications

Server-side applicability is already at a point where most companies’ programming needs are met. CGI is still an effective server application technique and still works with most Web servers. If your company uses Internet Information Server, Active Server Pages is still a viable application option, just as LiveWire is for Netscape’s Enterprise Server.

One change you may see more of is the use of CORBA/COM technology and distributed processing, with Web servers acting as one hub within a distributed network. Browsers might become “interface containers” rather than Web page processing tools. With the increased sophistication of Dynamic HTML, it won’t be long before you might be creating a Web page as the front end for a company application, in addition to using tools such as Visual Basic or PowerBuilder.

VRML

VRML is a wonderful idea that’s still looking for that killer application to take it out of the artist’s realm and plunk it directly into business.

Consider VRML’s concept, which is that you send a simple text file to a VRML-capable reader, which then renders the text contents into incredible, interactive 3D “worlds.” This is Internet technology at its best, as you have seen already with HTML, and will probably see with XML.

With VRML 2.0, the living world specification and the capability to integrate Web page scripting and VRML worlds, you are going to see more of this technology in use, for store catalogs, Web site maps, educational tools, and yes, even to play games and have a little fun.

XML and Channels

Neither XML nor channel technology, which are related, has found a niche yet, but with the release of CDF technology from Microsoft and Netcaster from Netscape, this should change.

The concept of push technology started with a bang at PointCast’s release, and almost disappeared without even a whimper–a case of too much hype and not enough efficient technology. In addition, the channel content just wasn’t there.

The entry of Netscape and Microsoft into the channel technology can only boost the use of this technology. Already, there is an increased number of companies providing channels. Add in those companies that are using the Marimba Castanet technology, and you should see an increased number of channels from diverse Web sites in the next year.

XML is the Extended Markup Language standard that basically adds the concept of extending Web page HTML to include new objects–objects related to the company’s business, based on some topic, or even packaged for reuse.

Microsoft and Marimba have proposed the use of CDF (Channel Definition Format) with the use of XML for use with channel technology. Apple has used a precursor of XML to create 3D Web site maps that are generated automatically; your reader can traverse to determine which page to access.

You can read more about XML at the W3C site at http://www.w3.org/XML/. You can read more about Microsoft and Netscape’s implementation at their respective sites or in Chapter 34, “XML.”

Summary

Where will you be in the future of Web development? Not all that far from where you are now. New technologies seem as if they are popping up all the time–but they need time to get absorbed into the mainstream of Web sites.

One technique to begin incorporating the new technologies is to create a special set of pages for your Web site–not your main pages, but those that can demonstrate a product or idea and use the new technologies. A set of pages for the Web site shown in Figures 37.3, Figure 37.4, and Figure 37.5 are viewable only by Netscape Navigator 4.0 and Internet Explorer 4.0; these are additional pages to a Web site, but the sites themselves use mostly mainstream technology, meaning some use of CSS1, scripting, some CSS1 positioning, HTML tables, and just plain text.

The Web pages use Dynamic HTML to hide and display content, as well as hide and display the menu. The page also uses CSS1 positioning to lay out the HTML elements.

The technologies discussed in this book are effective today, and will be effective into the year 2000. Best of all, they won’t break on New Year’s Day, 2000.

Categories
JavaScript

Adding Persistence to DHTML Effects

Originally published at Netscape Enterprise Developer, now archived at the Wayback Machine

Dynamic HTML (DHTML), implemented in Netscape Navigator 4.x and Microsoft Internet Explorer 4.x, gives the Web page visitor the ability to alter the position, format, or visibility of an HTML element. However, the effects that are created with DHTML are transitory in that the next time the page is refreshed, the current DHTML state is not maintained and the page opens showing the same content layout as when the page is first loaded. Any changes to the content based on DHTML are not maintained. Sometimes this isn’t a problem, but other times this is irritating to the reader. This article covers how to add persistence to a DHTML page. Examples should work with all forms of Netscape Navigator 4.x and Internet Explorer 4.x, but have only been tested with IE 4.x and Netscape Navigator 4.04 in Windows 95.With DHTML, developers can provide functionality that hides or shows whichever layer the Web page reader wants to view. Developers can also add functionality that lets readers move content. The problem is that DHTML effects are not session persistent, which means that they aren’t maintained between page reloads. Following a link to another site and returning to the page can trigger a reload, which wipes out the effect and annoys the user,. especially if he or she has spent considerable effort achieving the current DHTML state.

For example, you can use DHTML to let your reader position your page contents for maximum visibility in her browser and get the page look just right. If she decides to leave your site to check Yahoo’s news for a few minutes and then comes back, her settings will have been erased.

So, what’s the solution to these problems? It’s relatively simple — add document persistence using Netscape-style cookies.

Using cookies 
Despite the name, you won’t find Netscape-style cookies at your local bakery. Cookies are bits of information in the form of name-value pairs that are stored on the client’s machine for a set period of time or until the browser is closed. For security, cookies are created and accessed using specific syntax, are limited to 300 cookies total within the cookie database at 4K per cookie, and are limited to 20 cookies per domain (the URL where cookie was set).

Cookie syntax consists of a string with URL characters encoded, and may include an expiration date in the format:

Wdy, DD-Mon-YY HH:MM:SS GMT

Netscape has a complete writeup on cookies (see our Resource section at the end), including functions that can be copied and used to set and get cookies. I created modified versions of these functions to support my DHTML effects. As I don’t want to add to overly burdened cookie files, I don’t set the expiration date, which means the cookie does not get stored in the persistent cookie database or file. This also means that the DHTML effect only lasts for the browser session. However, this fits my needs of maintaining a persistent DHTML state in those cases where the reader moves to another site or hits the reload button.

DHTML state cookie functions
I created a JavaScript source code file called cookies.js that has two functions. One function sets the cookie by assigning the value to the document.cookie object. More than one cookie can be set in this manner, as cookie storage is not destructive — setting another cookie does not overwrite existing cookies, it only adds to the existing cookie storage for the URL. The cookie setting function is shown in the following code block:

// Set cookie name/value
//
function set_cookie(name, value) {
   document.cookie = name + "=" + escape(value);
}

Next, the function to get the cookie accesses the document.cookie object and checks for a cookie with a given name. If found, the value associated with the cookie name is returned, otherwise an empty string is returned. The code for this function is:

// Get cookie given name
//
function get_cookie(Name) {
  var search = Name + "="
  var returnvalue = "";
  if (document.cookie.length > 0) {
    offset = document.cookie.indexOf(search)
    if (offset != -1) { // if cookie exists
      offset += search.length
      // set index of beginning of value
      end = document.cookie.indexOf(";", offset);
      // set index of end of cookie value
      if (end == -1)
         end = document.cookie.length;
      returnvalue=unescape(document.cookie.substring(offset, end))
      }
   }
  return returnvalue;
}

That’s it to set and get cookie values. The next section shows how to create two Web pages with simple, cross-browser DHTML effects. Then each page is modified to include the use of cookies to maintain DHTML state.

_BREAK1 Creating the DHTML Web pages
To demonstrate how to add persistence to DHTML pages, I created two Web pages implementing simple DHTML effects. The first page layers content and then hides and shows the layers based on Web-page reader mouse clicks. The second page has a form with two fields, one for setting an element’s top position and one for setting an element’s left position. Changing the value in either field and clicking an associated button changes the position of a specific HTML element.

Adding DHTML persistence for layered content
For the first demonstration page, a style sheet was added to the top of the page that defines positioning for all DIV blocks, formatting for an H1 header nested within a DIV block, and three named style sheet classes. The complete style sheet is shown here:

<STYLE type="text/css">
        DIV { position:absolute; left: 50; top: 100; width: 600 }
        DIV H1 { font-size: 48pt; font-family: Arial }
        .layer1 { color: blue }
        .layer2 { color: red }
        .layer3 { color: green }
</STYLE>

Next, three DIV blocks are used to enclose three layers, each given the same position within the Web page. Each block also contains a header (H1), with each header given a different style-sheet style class. The HTML for these objects is:

<DIV id="layer1">
<H1 class="layer1">LAYER--BLUE</H1>
</DIV>
<DIV id="layer2" style="visibility:hidden">
<H1 class="layer2">LAYER--RED</H1>
</DIV>
<DIV id="layer3" style="visibility:hidden">
<H1 class="layer3">LAYER--GREEN</H1>
</DIV>

That’s it for the page contents. To animate the page, I created a JavaScript block that contains a global variable and two functions. The global variable maintains the number of the layer currently visible. The first function is called cycle_layer; this function determines which layer is to be hidden and which is shown next, and then calls a function that performs the DHTML effect:

<SCRIPT language="javascript1.2">
<!--

// current layer counter
current_layer = 1;

// assign document clicks to function pointer
document.onclick = cycle_layer;

// cycle through layers
function cycle_layer() {
   var next_layer;
   if (current_layer == 3)
        next_layer = 1;
   else
        next_layer = current_layer + 1;
   switch_layers(current_layer, next_layer);
   current_layer = next_layer;
}

The scripting block also assigns the function cycle_layer as the event handler function for all mouse clicks that occur within the document page. By doing this, clicking any where in the page document area that doesn’t include any other content results in a call to the function to change the layer.

The switch_layers function is the DHTML effects function, and it uses the most uncomplicated technique to handle cross-browser differences: it checks for browser type and then runs code specific to the browser. Other techniques can be used to handle cross-browser differences, but these are outside of the scope of this article. All that the function does is hide the current layer and show the next layer in the cycle, as shown here:

// hide old layer, show new
function switch_layers(oldlayer, newlayer) {
   if (navigator.appName == "Microsoft Internet Explorer") {
        document.all.item("layer" + oldlayer).style.visibility="hidden";

        document.all.item("layer" +
newlayer).style.visibility="inherit";
        }
   else {
        document.layers["layer" + oldlayer].visibility="hidden";
        document.layers["layer" + newlayer].visibility="inherit";
        }
}

Try out the first sample page. Clicking on the document background, not the text, changes the layer. Try setting the layer to the green or red layer, accessing another site using the same browser window, and returning to the sample page. When you return, the page is reset to the beginning DHTML effect, showing the blue layer.

To correct the loss of the DHTML effect, we can add persistence to the page by storing which layer is showing when the page unloads. This information is captured in a function called when the onUnLoad event fires.

To add persistence, I added the cookies Javascript source code file to the page, using an external source code reference:

<!-- add in cookie functions -->
<SCRIPT language="javascript" src="cookie.js">
</SCRIPT>

Next, I added the function to capture the DHTML state:

// onunload event handler, capture "state" of page (article)
function capture_state() {
   set_cookie("current_layer",current_layer);
}

When the page reloads, the onLoad event is fired, and a function is called from this event to “redraw” the DHTML effect. The function is called start_page, and it pulls in the cookie containing which layer should be shown:

function start_page() {
// get cookie, if any, and restore DHTML state
  current_layer = get_cookie("current_layer");
  if (current_layer == "")
        current_layer = 1;
  else
        switch_layers(1, current_layer);
}

Finally, the two event handlers, onUnLoad and onLoad, are added to the BODY HTML tag:

<BODY onload="start_page()" onunload="capture_state()">

You can try out the second sample page, which has DHTML persistence — again, change the layer, open some other site and then return to the sample page. This time, the DHTML effect persists during a page reload.

Sometimes an effect requires more than one cookie, as the next example demonstrates.

_BREAK2 Adding DHTML Persistence for Positioned Content
In the next example, I used a style sheet again to define CSS1 and CSS-P formatting for the DIV block that is going to be moved in the page:

<STYLE type="text/css">
        DIV { position:absolute; left: 50; top: 100; width: 600 }
        DIV H1 { font-size: 48pt; font-family: Arial }
        .layer1 { color: blue }
</STYLE>

Next, I created a form that has two text elements and associated buttons. One text and button element pair is used to change the DIV block’s top position, one pair is used to change the DIV block’s left position. The entire form is shown here:

<DIV id="first" style="position:absolute; left: 10; top: 10; z-index:2">
<form name="form1">
Set new Left Value: <input type="text" name="newx" value="50">
<input type="button" onclick="newleft(newx.value)" value="Set New
Left"><p>
Set new Top Value: <input type="text" name="newy" value="100">
<input type="button" onclick="newtop(newy.value)" value="Set New Top">
</form>
</DIV>

Next, the positioned DIV block is created:

<DIV id="layer1" style="z-index: 1">
<H1 class="layer1">LAYER--BLUE</H1>
</DIV>

Once the page contents have been created, you can add code to animate the DIV block based on whether the top or left position is changed. The function to change the top position is:

// change top value
function newtop(newvalue) {
   if (navigator.appName == "Microsoft Internet Explorer")
        layer1.style.pixelTop = parseInt(newvalue);
   else
        document.layer1.top = newvalue;
}

Again, the least complex technique to handle cross-browser differences is used, which is to check for the browser being used and run the appropriate code. The function to change the left position is identical to the top position function, except the CSS-P attribute “left” is changed rather than the CSS-P attribute “top”:

// change left value
function newleft(newvalue) {
   if (navigator.appName == "Microsoft Internet Explorer")
        layer1.style.pixelLeft = parseInt(newvalue);
   else
        document.layer1.left = newvalue;
}

That’s it for this page. You can try it out on the third sample page, where you can change the position of the DIV block by changing the left position, the top position, or both. Again, open another site in the browser and then return to the example page. Notice how the position of the DIV block does not persist between page reloadings.

Adding persistence to this page is very similar to adding persistence to the layered example page, except two values are maintained: the top and left values. The start_page and capture_state functions for this DHMTL effect are:

function start_page() {
// get cookie, if any, and restore DHTML state
  var tmpleft;
  tmpleft = get_cookie("currentleft");
  if (tmpleft != "") {
        currentleft = parseInt(tmpleft);
        currenttop = parseInt(get_cookie("currenttop"));
        newtop(currenttop);
        newleft(currentleft);
        if (navigator.appName == "Microsoft Internet Explorer") {
           document.forms[0].newx.value=currentleft;
           document.forms[0].newy.value=currenttop;
           }
        else {
           document.first.document.forms[0].newx.value = currentleft;
           document.first.document.forms[0].newy.value = currenttop;
           }
        }
}

function capture_state() {
        set_cookie("currentleft", currentleft);
        set_cookie("currenttop", currenttop);
}

To see how it works, try out the fourth sample page, move the DIV block, open another Web site in the browser and return to the example page. This time the DHTML effect does persist between page reloadings.

Summing up
In a nutshell, the steps to add persistence to a page are:

  1. Create the DHTML page
  2. Determine the values that must be maintained to re-create an existing effect
  3. Add the Netscape-style functions to the page
  4. Capture the onUnLoad event and call a function to capture the DHTML effect persistence values
  5. Capture the onLoad event and call a function to restore the DHTML effect from the persisted values

Using Netscape-style cookies to maintain DHTML effects won’t help with some DHTML persistence problems. For example, DHTML effects can be lost when a page is resized. In addition, if a page is resized between the time the DHTML persistence values are stored and the page is reloaded, the values may no longer work well with current page dimensions. However, for most effects and for most uses, the use of Netscape-style cookies is a terrific approach to DHTML persistence.