So, how does it work? Here is another look at the SpeedScript added for the Web object in w-cstget.w:
FIND customer WHERE Customer.CustNum EQ
INTEGER(customer.CustNum:SCREEN-VALUE IN FRAME {&FRAME-NAME}) NO-ERROR.
Every Web object that maps to a Web page requires a query mechanism that specifies the data that you want to retrieve from a database. In this case, you use the FIND statement to retrieve the Customer record whose CustNum field (Customer.CustNum) equals the value entered for Enter Customer ID in the Web page. The HTML form element that accepts the entered value is specified by the notation, CustNum:SCREEN-VALUE IN FRAME {&FRAME-NAME}.
This notation identifies a particular SpeedScript field object in the Web object's form buffer (FRAME {&FRAME-NAME}). The form buffer is a Web object buffer where all HTML form element values are stored, both for input from and output to a Web page. A field object is a SpeedScript construct that defines the visualization of a particular value stored in the form buffer. That is, a field object determines whether the value is represented by a string of characters, a selection list, a radio set, or some other visual control that is compatible with a corresponding HTML form element. The mapping between a field object and form element is done by a different procedure for each display type. The procedures are located in install-path/src/web/support. The procedures used for each display type are defined in a tag mapping file, install-path/tagmap.dat, which comes installed with default mappings.
Note: The SpeedScript form buffer is identical in function to the Progress ABL screen buffer. The screen buffer is the buffer from which individual field objects are displayed directly on the screen of a client workstation in a traditional client/server environment. However, SpeedScript access to the client screen is entirely determined by the HTML that it outputs as a block to the Web server. It is essential that you remember this difference when you consult Progress ABL documentation while doing WebSpeed development. For more information on how input and output differs between the Progress ABL and SpeedScript, see SpeedScriptand Progress ABL.
Using the Automap feature of the AppBuilder, WebSpeed defines database field objects by default for HTML form elements that have the same names. Thus, in this case, the form element name is CustNum, the database field name. You can also have the AppBuilder map a form element to another database field or SpeedScript variable field object with any valid SpeedScript name up to 32 characters.
The visual characteristics of a field object are defined by properties or attributes associated with that object. In this case, the FIND statement references the SCREEN-VALUE attribute of the CustNum object and is separated from the field object name by a colon (:). The SCREEN-VALUE attribute stores the actual form element/data item value in character string form. For information on setting field object properties and attributes see Customizing field object control handlers.
SpeedScript also requires each field object to be defined within a special container object known as a frame. This SpeedScript frame is not to be confused with HTML frames. It is just another way that SpeedScript organizes field objects in the form buffer. Typically, there is one frame per Web object, identified by the preprocessor name reference, {&FRAME-NAME}, hence CustNum:SCREEN-VALUE IN FRAME {&FRAME-NAME}.
Note: When you compile an HTML-mapping Web object in the AppBuilder, it might tell you that it cannot find a particular field object in a frame. You can often resolve this by appending IN FRAME {&FRAME-NAME} to the problem field object reference.
The FIND statement also references the CustNum object as input to the SpeedScript INTEGER function. This function simply converts the numeric string value of the field object to an integer for compatibility with the CustNum database field, which is also an integer.