Execution of Server-Side Triggers and Operations

In DSPs, triggers and operations that are to be executed on the server are declared with the trigger and operation ProcScript instructions. When called at runtime, a sequence of events occurs in which the browser sends a request to the server, the server processes the request and generates a response, and the browser processes the response. This is the server request-response exchange.

In static server pages, the exchange is synchronous, and the response causes the entire page to be reloaded. In dynamic server pages, both the request and the response are asynchronous, and the response can update data in the page without reloading the complete page.

Editing data in a field, pressing a button, or clicking a link are all actions that might initiate a request to execute a trigger (such as detail or OnEdit) or activate an operation. Server-side triggers and operations can only be called from the browser if the client-side of the DSP instance has the information needed to call them. This information is added to the trigger or operation definition using the public web instruction. This is essential for security to ensure that possible malevolent code in the browser cannot access server-side code. Only triggers and operations that are explicitly made public to the web, can be called from the web.

Activating a Detail Trigger

Consider a CommandButton widget that has a detail trigger that stores data:

trigger detail
public web       
  if ($occdbmod(<$entname>) = 1)
    store/e "<$entname>"
    if ($status < 0)
      MESSAGELINE = "Store failed ($status = %%$status%%%)."
      return 0
    endif
    commit
    if ($status < 0)
      MESSAGELINE = "Commit failed ($status = %%$status%%%)."
      return 0
    endif
    MESSAGELINE = "Store successful."
  else
    MESSAGELINE = "No modifications."
  endif
  return 0
end; detail

The trigger must be public web, otherwise it is not even available to the browser.

When the user clicks the button, the following sequence of events is initiated:

  1. The browser uses the scope information defined in the DSP to:
    1. Collect the data that needs to be sent to the server.
    2. Block the target data elements in which the response will be loaded, as well as user events, and triggers or operations that are included in the scope.

    Because there is no scope explicitly set, the default is used which is that all data in the DSP instance is included in the request and blocked in the browser.

  2. The browser adds the request to activate the detail trigger to its request queue. It includes information about the component, instance name, and trigger to be activated, as well as the user data to be stored.
  3. When the request reaches the top of the queue, the browser sends the request to the web server. Queuing is based on dependencies. For example, if the data in the request is already blocked by a previous request, it won't reach the top of the queue until a response is received that unblocks the data.
  4. The web server redirects the request via the WRD to the Uniface Server.
  5. The Uniface Server instantiates the requested DSP component using the provided instance name.
  6. The preActivate trigger of the component instance is fired. ProcScript in this trigger typically restores state information by loading server-side state and client-side state into the component. The preActivate trigger's default ProcScript will:
    1. Load the data received from the browser as disconnected records in the component (webload)
    2. Reconnect the disconnected records with database and component data (reconnect)
    3. Apply the current occurrence context of the browser to the component data (websetocc)
  7. The requested detail trigger is fired and its ProcScript is executed.
  8. The postActivate trigger of the component instance is fired. ProcScript in this trigger typically stores state information for a next request-response cycle:
    • Save server-side state from the component into, for example, the database.
    • Save client-side state from the component into a browser response using the default ProcScript (websave)
  9. The response is returned to the browser via the web server.
  10. The browser loads the data from the response into the target data elements.
  11. The target data elements are unblocked.

Related Topics