Binding 4D objects with HTML objects

Home

4D v16.3

4D's Web server lets you recover "posted" data, i.e. data entered by users through Web forms and sent to the server by means of buttons or interface elements, in POST mode or in GET mode.

The Web server accepts several specific URLs that can be associated with buttons so that the submission of the form triggers server-side processing. These URLs are described in the URLs and Form Actions section.

This chapter covers the principles implemented in order to recover data found in forms that were returned to the server.

Receiving dynamic values

When the 4D Web server receives a posted form, 4D can retrieve the values of any HTML objects it contains. This principle can be implemented in the case of a Web form, sent for example using WEB SEND FILE or WEB SEND BLOB, where the user enters or modifies values, then clicks on the validation button. In this case, there are two ways that 4D can retrieve the values of the HTML objects found in the request:

using the WEB GET VARIABLES command, or
using the WEB GET BODY PART and WEB Get body part count commands.

The WEB GET VARIABLES command retrieves the values as text, while the WEB GET BODY PART and WEB Get body part count commands can retrieve the files posted, using BLOBs.

Compatibility note (4D v13.4): In previous versions, 4D copied the values of variables received by means of a posted Web form or a GET URL directly into 4D process variables (in compiled mode, these variables had to have been declared in the COMPILER_WEB method). This functioning is removed starting with 4D v13.4; it is maintained by compatibility in converted databases but can be disabled using the Automatic variable assignment compatibility option on the Compatibility page of the Database Settings (we recommend that you uncheck this option and use the WEB GET VARIABLES or WEB GET BODY PART commands in your databases).

Consider the following HTML page source code:

<html>
<head>
  <title>Welcome</title>
  <script language="JavaScript"><!--
function GetBrowserInformation(formObj){
formObj.vtNav_appName.value = navigator.appName
formObj.vtNav_appVersion.value = navigator.appVersion
formObj.vtNav_appCodeName.value = navigator.appCodeName
formObj.vtNav_userAgent.value = navigator.userAgent
return true
}
function LogOn(formObj){
if(formObj.vtUserName.value!=""){
return true
} else {
alert("Enter your name, then try again.")
return false
}
}
//--></script>
</head>
<body>
<form action="/4DACTION/WWW_STD_FORM_POST" method="post"
 name="frmWelcome"
 onsubmit="return GetBrowserInformation(frmWelcome)">
  <h1>Welcome to Spiders United</h1>
  <p><b>Please enter your name:</b>
  <input name="vtUserName" value="" size="30" type="text"></p>
  <p> 
<input name="vsbLogOn" value="Log On" onclick="return LogOn(frmWelcome)" type="submit"> 
<input name="vsbRegister" value="Register" type="submit">
<input name="vsbInformation" value="Information" type="submit"></p>
<p> 
<input name="vtNav_appName" value="" type="hidden"> 
<input name="vtNav_appVersion" value="" type="hidden"> 
<input name="vtNav_appCodeName" value="" type="hidden">
<input name="vtNav_userAgent" value="" type="hidden"></p>
</form>
</body>
</html>

When 4D sends the page to a Web Browser, it looks like this:

The main features of this page are:

It includes three Submit buttons: vsbLogOn, vsbRegister and vsbInformation.
When you click Log On, the submission of the form is first processed by the JavaScript function LogOn. If no name is entered, the form is not even submitted to 4D, and a JavaScript alert is displayed.
The form has a POST 4D Method as well as a Submit script (GetBrowserInformation) that copies the Navigator properties to the four hidden objects whose names starts with vtNav_App.
It also includes the vtUserName object.

Let’s examine the 4D method WWW_STD_FORM_POST that is called when the user clicks on one of the buttons on the HTML form.

  // Retrieval of value of variables

 ARRAY TEXT($arrNames;0)

 ARRAY TEXT($arrValues;0)

 WEB GET VARIABLES($arrNames;$arrValues)

 C_TEXT($user)

 

 Case of

 

  // The Log On button was clicked

    :(Find in array($arrNames;"vsbLogOn")#-1)

       $user :=Find in array($arrNames;"vtUserName")

       QUERY([WWW Users];[WWW Users]UserName=$arrValues{$user})

       $0:=(Records in selection([WWW Users])>0)

       If($0)

          WWW POST EVENT("Log On";WWW Log information)

  // The WWW POST EVENT method saves the information in a database table

       Else

 

          $0:=WWW Register

  // The WWW Register method lets a new Web user register

       End if

 

  // The Register button was clicked

    :(Find in array($arrNames;"vsbRegister")#-1)

       $0:=WWW Register

 

  // The Information button was clicked

    :(Find in array($arrNames;"vsbInformation")#-1)

       WEB SEND FILE("userinfos.html")

 End case

The features of this method are:

The values of the variables vtNav_appName, vtNav_appVersion, vtNav_appCodeName, and vtNav_userAgent (bound to the HTML objects having the same names) are retrieved using the WEB GET VARIABLES command from HTML objects created by the GetBrowserInformation JavaScript script.

Out of the vsbLogOn, vsbRegister and vsbInformation variables bound to the three Submit buttons, only the one corresponding to the button that was clicked will be retrieved by the WEB GET VARIABLES command. When the submit is performed by one of these buttons, the browser returns the value of the clicked button to 4D. This tells you which button was clicked. Note that 4D buttons in a 4D form are numeric variables. However, with HTML, all objects are text objects.

If you use a SELECT object, it is the value of the highlighted element in the object that is returned in the WEB GET VARIABLES command, and not the position of the element in the array as in 4D.

WEB GET VARIABLES always returns values of the Text type.

Support of chunked transfer encoding

Starting with 4D v15 R3, the built-in 4D Web Server supports files uploaded in chunked transfer encoding from any Web client. Chunked transfer encoding is a data transfer mechanism specified in HTTP/1.1. It allows data to be transferred in a series of "chunks" (parts) without knowing the final data size.

Note: The 4D Web Server also supports chunked transfer encoding from the server to Web clients (see WEB SEND RAW DATA).

For more information about client-side implementation for chunked transfers, please refer to RFC7230 or the related page on Wikipedia.

COMPILER_WEB Project Method

The COMPILER_WEB method, if it exists, is systematically called when the HTTP server receives a dynamic request and calls the 4D engine. This is the case, for example, when the 4D Web server receives a posted form or a URL containing the 4DCGI/ action. This method is intended to contain typing and/or variable initialization directives used during Web exchanges. It is used by the compiler when the database is compiled. The COMPILER_WEB method is common to all the Web forms. By default, the COMPILER_WEB method does not exist. You must explicitly create it.

Web Services: The COMPILER_WEB project method is called, if it exists, for each SOAP request accepted. You must use this method to declare all the 4D variables associated with incoming SOAP arguments, for all methods published as Web Services. In fact, the use of process variables in Web Services methods requires that they be declared before the method is called. For more information on this point, refer to the description of the SOAP DECLARATION command.