Because the World Wide Web uses pages instead of objects, special design considerations are required for Web forms. With Microsoft Exchange, if you send a message addressed to an invalid recipient, your message information remains intact in the message object, though the message is not delivered. You can readdress the message and send it again.
This model of data persistence cannot be transferred from a traditional messaging system to the Web. If a person types message information on a Web page and submits the page, that Web page disappears and a new page appears. This new page can be passed the user's information and can send it. But if this send attempt fails, perhaps because of an invalid recipient, the original page (along with the user's information) is gone. At this point, there is no convenient way to repopulate the fields with the user's message information.
The Classified Ad sample application has a solution to this problem that uses a three-part model. It uses the three script files RootComp.asp, Resolve.asp, and Compose.asp, as shown in the following diagram. (More frames are actually used than those shown here; this diagram is meant to illustrate merely how data is preserved.)
The files and frames in this illustration work together in the following manner.
At the Microsoft® Outlook™ Web Access interface, the user clicks a link that creates and renders a new classified ad. The first script called is RootComp.asp, which initializes and ties together two frames — Compose and Resolve — in one frameset. Since Resolve and Compose are two frames on the same page, both are running simultaneously.
The Resolve frame first checks a variable called sendRequest. If this variable has not been set to the value sendMessage, Resolve does not process the message. This mechanism is meant to keep Resolve from trying to process message information before the user has entered it. (At startup, VBScript automatically initializes the sendRequest variable to Nothing.)
Resolve displays a caption, but no tags for user input. Meanwhile, the Compose frame displays a form containing HTML controls with which the ad's creator enters information about offered or sought items. During this time, Compose sets the sendRequest variable to sendMessage.
When finished entering information, the user clicks Send on the Compose frame. Control is now passed to Resolve, which, because sendRequest has been set to sendMessage, begins processing the message. Resolve requests the entered data from Compose, using the Request object in this manner:
szWorkPhone = Request.Form ("WorkPhone")
The Resolve frame now creates the new message object, adds fields for the data gathered from Compose, and sets their values. It also sets the form's type. For more information on these actions, see the following section.
Resolve checks essential fields and, if important data is missing or invalid (such as if the destination name does not resolve), it displays an alert to notify the user of the error. The user can now re-enter information at the Compose page, which still holds all the original information. If Resolve determines that the information is valid this time, it sends the message.