Cookies

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

When you create a customizable Web Part, the customization generally takes place inline in the dashboard. However, you also must make sure that other pages are supported.

For example, a Web Part that shows the contents of a Microsoft® Outlook® folder using the Outlook View control must be capable of showing the contents of any folder that the user chooses at run time. To do this, the Web Part must have information about which folder to display and possibly the name of a stored view to use. You can provide this type of functionality using client-side cookies.

The Web Part displays a user interface that makes it possible for a user to change the current folder or view. When the user changes the view, the Web Part uses client-side script to write a cookie containing the configuration information. When the user refreshes the dashboard or returns to it in another session, the Web Part uses the client-side script to read the cookie value and reapply the configuration information.

You can access cookies through the document object model (DOM). The code for this is document.cookie.

Although writing client-side cookies is the easiest way to store and retrieve user settings, these setting are confined to the client computer. A user cannot log onto another computer in the network and view the customized Web Part. If your Web Part includes embedded script that runs on the server, then that embedded script can access cookies passed by Microsoft® Internet Explorer through the Request.Cookies collection in Active Server Pages (ASP).

See Also

Developing a Digital Dashboard Using Web Parts | Guidelines for Building Good Web Parts | The CustomizationLink Property | The PartStorage Property | Cookies and Non-Isolated Content