Using the frameset

Professional Edition onlyBusiness Edition only Launching the customer care applet in a frameset separates the applet code from the code in the store pages. As the diagram above illustrates, the store pages are contained in the main frame of the frameset, while the applet code is contained in the Sametime frame. By separating the applet code from the store pages you reduce network traffic, as the applet is only downloaded once.

Using a frameset also allows you to maintain the connection with the Sametime server. If the applet was part of each page and not the frameset, a new Sametime session would be created each time a customer accessed a new page. Since the customer care applet logs on to the Sametime server anonymously, creating a new session each time a customer accessed a new page would not allow you to trace the customers activities through the store. Using the frameset, the customer's original Sametime session is maintained, and the customer's activities are sent back to the Sametime server as attributes change.

Although using a frameset is the recommended method to implement Customer Care in your store, you should be aware of the following issues with using framesets:

Single point of entry
Customers can only use customer care if they browse your store within the framework. Likewise, CSRs can only monitor customer movement through the frameset. To ensure that customers are browsing the store via the frameset, they must access the site through a single entry point. If a customer accesses your store through another page (for example, a catalog page), they will not be in the frameset.
Bookmarking
When using the frameset customers will only be able to bookmark the URL of the frameset, not individual pages.
Refreshing
When a customer is in the frameset and clicks refresh, they will be taken back to the original page, as coded in the frameset, which may not be the same page that is currently displaying in the browser.
Resizing browser window
If a customer resizes the browser window while in the frameset, the browser may automatically reload the entry address. If the entry address is reloaded, the connection to the Sametime Server may be terminated. Different browsers behave differently in this situation.
Security
In order to work correctly, pages within the customer care frameset must be able to communicate with each other. This communication is enabled by JavaScript function calls. When a customer is browsing a site through a frameset, each individual frame, as well as the frameset (the URL in the location bar) maintains its own connection, either unsecure (http, by default port 80) or secure (https, by default port 443). If a customer is browsing the store using an unsecure connection all frames within the frameset are in HTTP. In this scenario there are no issues with SSL. However, if the customer browses to a secure page (for example, the registration page), the main frame within the frameset will switch to HTTPS, while the rest of the frames remain unsecure (http). In this situation, a customer will not be able to launch the customer care applet. The browser will not authorize launching the applet, because the JavaScript function that calls the applet (secure, port 443) appears to be coming from a different server than the URL in the location bar of the browser (HTTP, port 80). To solve this problem, you should always use the StoreFramesetView command to enter the store, as it will enforce the HTTPS connection for the frameset URL.

In order to communicate between frames, the Java applet and JavaScript functions also must communicate. Since the applet code base is on the Sametime server, not the WebSphere Commerce Server, some browsers (for example Netscape versions 6 and 7) that use the Sun Java plug-in prevent the JavaScript from communicating with Java applets that are loaded from a different host.

Feedback