Data Formatting on Server (serverDataFormatting)
DSP widget property that disables client-side formatting and syntax checking for non-String fields. Instead, the server side is responsible for formatting data for display, deformatting it for storage, and syntax checking submitted data. True or False
|
Attribute |
Value |
|---|---|
| Physical Property Name | serverDataFormatting |
| Property Type | uboolean |
| Dynamic? | Yes |
| Default value | Depends on the Uniface Data Type |
|
Value |
Description |
|---|---|
|
|
Server-side formatting and deformatting is enabled. |
|
|
Client-side formatting and deformatting is enabled for non-String data types. |
Usage
|
Dynamic? |
No |
|
Default value: |
|
Description
In dynamic server pages (DSPs), the way in which data is formatted for display depends on the type of widget, the Uniface data type, and the specified display format.
For fields with Data Type String, all formatting and deformatting is performed on the server side, regardless of the value of the property Data Formatting on Server. Data is transported as a formatted string, and the triggers formatToDisplay and formatFromDisplay can be used to customize the way the data is formatted.
For fields with a non-String Data Type, such as Numeric, Boolean, or Date, the default behavior is to perform formatting (and deformatting) in the DSP client. Data is transported as an unformatted value. The client applies display formats, and deformats it before sending data to the server. If Syntax Check on Browser is true, the syntax of data is also checked on the client before the data is sent.
In some cases, you may want have non-String data formatted on the server instead of the client. For example, you want to use a display format with symbols and patterns that can't be handled by client-side formatting in DSPs, or you want to perform special logic with a value, such as setting the coordinates in a Google map.
To do so you can set the Data Formatting on Server to True, which has the following effects:
- Data formatting and deformatting are handled by the server. For example, display formats and the $nlslocale are applied.
- The triggers formatToDisplay and formatFromDisplay are executed, enabling you to control how data is formatted for display and deformatted for storage.
- Data is transported as a formatted string and displayed as-is in the widget.
- Client-side syntax checking is disabled.
Caution: When server-side formatting is used, the DSP client does not validate the field syntax. It becomes the developer's responsibility to ensure the validity of the data submitted from client to server. It also means that a full round-trip to the server is required before the display can be updated or errors reported.
Data that is transported as a formatted string may have data loss as a result of the formatting. For example, a Numeric field containing a value such as 12345.67899 and a display format of 99999P99 is formatted as 12345.68. The loss of accuracy in the decimal points may be acceptable for display, but not for storage.
In this case, you must take special care to validate the data submitted from the client to ensure that it is not corrupted.
Applies To
Compatiblity
This property replaces the property datatype=string, formerly used in Uniface configuration files usys.ini, uweb.def, and web.ini. The property datatype=string continues to work, but if Data Formatting on Server is set, it overrides the datatype property.
