Domino profile documents
Profile documents are mysterious Domino creations, as they are created with a form, but they never appear in any views or in the database document count. Profile documents are excellent at storing user customization preferences for two reasons. First, when a profile document is created, you can give it a key such as @username, and later use the same key for retrieval of info from the document. The second reason is that profile documents are cached when the database is opened, so access to profile document data is speedy.

Unfortunately for Web developers, profile documents are almost useless in a browser. The same caching that makes profile documents so fast is incompatible with the HTTP (Hyper Text Transfer Protocol) engine's caching system, and thus causes huge headaches such as different HTTP engine threads having different versions of profile document caches. The Domino Designer documentation makes it seem like the commands @GetProfileField() and @SetProfileField() should work on the Web, and they do -- kind of. But the caching issues ensure you will never know if you have the latest profile document data.

Fortunately, it's easy enough to simulate the functionality of profile documents on the Web. This article will show you how to simulate a global profile document on the Web, and my next article will show you how to create user based profile documents for your Web applications.

The first article in this series showed you how to add a Web popup calendar that lets users select a date from a calendar to fill a field. One of the major advantages of this calendar is that it's a "pure Domino" solution, so customization is easy. To illustrate the profile document simulation technique, we will extend our popup calendar form, making it multilingual. Don't worry if you didn't read the last article (although I would recommend it), you don't need to know anything about how the popup calendar works to learn how to use profile forms on the Web.