Data Error Handling in Web Applications

Uniface always validates data before storing it to ensure that it conforms with declarative and procedural validation rules. You can customize the error handling and reporting using server-side and client-side triggers.

For example, multiple users can modify an entity occurrence simultaneously. In a web environment, you can only use optimistic locking, so when one user submits a change, another user may be modifying data that is already out of date. When the second user submits a change, the modification will not be accepted.

In this case, the user needs feedback, as well as the current data to try it again. Error triggers on the server and the client enable you to provide this feedback by customizing error handling and reporting.

If client-side field syntax checking is enabled, some field syntax errors can be detected in the client browser before data is submitted to the server. If client-side field syntax checking is disabled, or server-side formatting is enabled, such errors will be caught during server-side validation. For more information, see Syntax Checking in Web Applications and Data Formatting on Server (serverDataFormatting).

Default Error Handling

When new and modified data is submitted to the server (by webload and reconnect for DSPs, or webget for USPs), validation triggers are activated to ensure that the data meets all validation constraints. After the entire input stream has been processed, error triggers are fired for each occurrence that contained an error and could therefore not be connected to the database.

If the error trigger is not defined or empty, Uniface generates a default error message and this is returned to the browser in the response:

  • In entity-level error trigger, Uniface sets the default error message ($text("%%$error")) to $occproperties(Entity)="errormsg=$text(%%$error), but only if the trigger has been fired due to a validation error for a field or key.
  • In the field-level error trigger, Uniface sets the default error message to $fieldproperties(Field)="errormsg=$text(%%$error)

These errors are logged to the browser console, but to alert the user to the problem, you must do something with this error information, for example assign it to a field or display an alert box.

Default Error Visualization

The way in which error information is presented to the user differs between USPs and DSPs. By default:

  • In DSPs, websave generates a JSON stream. Fields that are in error are styled to alert the user that there is a problem.

    Uniface styles the field in error by means of a error class style (-ufld-highlight-error-) and CSS that applies a red border.

    If the DSP's layout also contains a bound error element (such as <span uflderror:FIELD.ENTITY.MODEL/>) for the field, it is assigned the error text. For more information, see Syntax Checking in Web Applications.

  • In USPs, webgen creates an HTML stream. In the default layout, there is a message area at the bottom of the page where the error is displayed.

Error Triggers

You can use the error trigger of entity occurrences and fields to customize the way errors are handled. For USPs, you can use this trigger visualize the error in the generated HTML.

For DSPs, there are web triggers that can be used to display and clear validation and syntax errors in the browser:

Formatting Errors

Uniface has to format data from its own storage format to a format that is usable in a web page. And it has to deformat the data entered by the user to one that matches the data storage format. This is usually straightforward for String data but can be more complex when handling Numeric, Float, Date, Time, and Datetime fields.

For example, Uniface supports a higher precision (the total number of digits that can be held or stored without changing the value) than JavaScript. To prevent data from being corrupted, Uniface checks that it can safely convert a number from Uniface to JavaScript or vice versa. If a value cannot be converted, an error is returned.

Factors that affect how data is formatted include the database interface, the widget type, and the display format. For Numeric, Float, Date, Time, and Datetime data types, Uniface supports a limited set of standard display formats in DSPs.

Uniface returns an error in the following circumstances:

  • Value cannot be formatted, for example a Number is too large to be displayed, or the value contains an invalid character.
  • Value cannot be formatted for the specified display format.
  • Display format is not supported.

Errors for server-side values and display formats are shown in the browser console. Errors for data entered by the user are returned as syntax errors.

For data formatting errors (for example a value with more decimals than are accepted by the field's display format), the value is displayed with asterisks and the error is displayed in the browser console.

For more information, see Display Formats for Date and Time in Dynamic Server Pages and Display Formats for Numeric and Float Data in Dynamic Server Pages.

USP Error Processing

This example shows how to use the error trigger in a USP to give feedback and the new data to the user. MESS is a non-editable field for displaying information on the server page, and SHARED_TABLE is an entity that can be modified by multiple users. In the error trigger of entity SHARED_TABLE, add the following ProcScript:

trigger error
  MESS="The data has been modified by someone else. %\
  Please try and submit it again."
  clear/e "SHARED_TABLE"
  retrieve/e "SHARED_TABLE"
  webgen
end

Related Topics