WebSpeed
Developer’s Guide
Moving Data Through the HTML Mapping Web Object
To help understand the impact of the default logic in process-web-request and some of the effects you can expect from overriding it, Figure 8–4 shows where the default event procedures move data in a Web object.
Figure 8–4: Data Flow Through an HTML-mapping Web Object
![]()
Frame Buffer and Record Buffer
The frame buffer is a Web object memory area for storing data that comes directly from HTML form input or that is being prepared for output to a Web page. This data is stored in a character string form that is compatible with its appearance in the Web page. Each data item is stored in a field object that corresponds to an HTML form element of the equivalent type. Thus, these field objects are windows into the frame buffer for each data item accessed by the Web object.
NOTE: The frame buffer in SpeedScript is equivalent to the screen buffer in the Progress 4GL. The difference is that for 4GL, each field object in the screen buffer supports interaction with a local keyboard and monitor. For SpeedScript, each field object in the frame buffer is a staging area for moving data to and from the Web. Any documentation provided with WebSpeed that references display values, screen values, or the screen buffer actually refers to the frame buffer and its data.The record buffer is a memory area for storing Web object variables and database field values that are directly output to or input from a database. Each data item is stored in the record buffer according to the native SpeedScript data type (character, integer, and so on) that is defined for the corresponding variable or database field. The record buffer is the most efficient Web object storage and serves as the working storage for all SpeedScript computations and database I/O.
inputFields Data Movement
For a request that comes in with form input, inputFields retrieves the values for all input elements listed in
tagmap.dat
and places them in the corresponding field objects of the form buffer. inputFields does this by calling the default web.input control handler defined for each form element type.NOTE: You can override the default web.input control handler in the New Section dialog box of the AppBuilder Section Editor.assignFields Data Movement
Each field object in the form buffer corresponds by name to an HTML form element. Each field object also corresponds to a named variable or database field in the record buffer. (If you do not select a database field, the AppBuilder can define a variable with a name that is similar to the corresponding form element name, or you can define your own variable or buffer and set the field source in the AppBuilder to User.) assignFields moves the current values stored in the form buffer to the corresponding variables and fields in the record buffer, converting them to the appropriate data type, if necessary.
NOTE: assignFields only moves data from field objects for which you have set the Enable property to Yes (the default) in the field object Property Sheet in the AppBuilder.Committed Transactions
At any point that the Transaction Agent or Web object commits the current database transaction (or subtransaction), any database records containing fields that were modified during the transaction (or subtransaction) are written to the database. This includes records modified by assignFields or by using SpeedScript directly. For more information on database transactions and subtransactions, see Controlling Database Transactions."
FIND Records
For a Web request, the typical database query returns one record (or one record per table in a join) from the database that provides the values for mapped field objects. Generally, you accomplish this using a single FIND statement. However, you might require other file I/O or calculations to provide the values for local variable or user field objects that are also mapped for the request. You can also retrieve records anywhere that is appropriate for your application, such as in a local override to an event procedure.
displayFields Data Movement
displayFields moves variable and field values from the record buffer to the form buffer, converting to formatted character strings, as appropriate. It also takes FORMAT options from the database or you can override these FORMAT options in the AppBuilder property sheet.
displayFields only moves data to field objects for which you have set the Display property to Yes (the default) in the field object Property Sheet in the AppBuilder.
enableFields Effects
enableFields modifies the SENSITIVE attribute of the appropriate field objects in the form buffer. If set to FALSE, text-oriented field objects are effectively prevented from receiving any input by the action of the default web.output control handler. For more information on these effects, see the code provided in install-path
\src\web\support\webinput.p
.enableFields only sensitizes field objects for input for which you have set the Enable property to Yes (the default) in the field object Property Sheet in the AppBuilder.
outputFields Data Movement
outputFields performs the main tasks required to provide a Web page to the Web server. This includes merging data from the form buffer into the mapped Web page. outputFields does this by calling the web.output control handler defined for each mapped form element and custom tag that it encounters in the output Web page.
If the default field object is not enabled for input and the corresponding form element is an <INPUT> tag of type TEXT, HIDDEN, or PASSWORD, the method outputs the text of the value in place of the form element tag. Because the form element tag is effectively deleted and replaced by plain text, the value represented by that text can never be changed by the user or returned as a value in a subsequent request with the form. Thus, the next request from the Web page arrives as if the form element never existed, and the corresponding web.input control handler never sees any input for it. For all other form element types, such as RADIO, the default web.input returns whatever data is there to the form buffer, but it is never assigned to a program variable or database field.
The Display property setting for a field object has no effect on outputFields. Whatever data happens to be in the form buffer is output.
The output for a form element is entirely up to you, especially if you define your own field object mapping or override the default web.output control handler. For example, you might interpret the value for the form element, replacing or combining it on output with an HTML reference to an image (using the <IMG> tag).
You can conditionally enable and disable field objects for input during each request, but only if you first define the field object as enabled for input using the Properties Sheet in AppBuilder. That done, you can then set the SENSITIVE attribute of the field object, as required at any point between the default execution of enableFields and outputFields.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |