Session management Professional
A major drawback of HTML based applications is that an HTML page is stateless. There is no state information available that would tell if an address form, for example, has been filled in already by a user so that the Web application can present the form with the correct data when the user reloads this particular HTML page. In the Klondike Computer Shop, there are two places where address data is required: the address entry form, and the purchase order form. It would be annoying for a user to have to type the same data twice in two places, so this is something a Web application must take care of and we are going to see how this is done most easily.
When you recall the discussion of the BuildAddressTable() function, you remember that the record pointer of the Customer database is moved "somehow" to the appropriate record before input controls are filled with data from the database. This is accomplished in the following way. When address data is submitted for the first time and stored in the Customer database, a session is opened by the Context object and data identifying the record is attached to this object. This data can be retrieved later from a Context object until either the session is closed or the Web browser on the remote station is terminated by the user.
Each record of the Customer database gets a date/time stamp when data retrieved from the HTML object is stored (lines #3-8). The date/time stamp serves as unique identifier so that records could be deleted by another application during a session (this could be the case when a purchase order is processed by another program, but is out of scope here). Immediately after data is written to the file, the session is opened in line #10 and the record number plus date/time stamp is attached to the Context object using the :setCargo() method in line #11. The data identifying this record is saved as an array along with the symbolic name ADDRESS_DATA.
The name ADDRESS_DATA is used for retrieving the array from the Context object when the address table is requested again from the remote station. This is done in line #18 and #19 where the session is opened again. If the array exists, the record pointer of the Customer database is positioned accordingly and the input controls are filled with data that are submitted already. If the array does not exist or if the date/time stamp does not match, the record pointer is moved to the ghost record, so that input controls are filled with empty data.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.