Web Properties

Creating and Maintaining a Web Application

Web Application Flow


The functional behavior of your web application can be coded in your DataFlex server-side application by setting properties, creating methods and creating event handlers.

Loading a View

The first time when a client (Browser) calls the server to load a view, the server will send to the client a structure of data that describes the view. This structure will contain a nested list of all web objects in the view and the set of properties belonging to each web object. The client uses these to create the visual representation of each web object and set up the user interface.


Web Properties

Web Properties are used to define data that are sent to the client for each web object. Only subclasses of the cWebObject class understand the web property interface.

Web Properties can be of type Client, ClientProtected, Server or ServerSession.


A special meta-data tag { WebProperty=[Type] } is used to identify which properties of a web object are web properties. For example: the psLabel property is understood by all web controls. The declaration for psLabel is as follows:

{ WebProperty=Client }

Property String psLabel ""

If an object sets the psLabel property...

Object oName is a cWebForm

    Set psLabel to "Name:"


Then the value of the psLabel property (“Name:”) is sent to the client when that object’s view is loaded.

Normally, the client object handles each web property that is sent to it and will perform defined actions according to their values. If a web property is sent to the client that the client object does not know, then its value is simply stored in the client object. This means that you can declare your own web properties and use them to store values at the client. For example:

Object oClicker is a cWebButton

    { WebProperty=Client }

    Property Integer piCountClick 0


In this example, the name-value pair piCountClick=0 is sent to the client when that object’s view is loaded.

Structs and Arrays are supported with web properties. While the creation of struct and array web properties is a powerful feature making it easy to store large amounts of data, developers should be aware that the data is sent back and forth with every request/response cycle. This could impact performance.

Note that RowId data-types are not supported for any type of web property, including structs and arrays. If you need to store RowIds, serialize them to a string using the SerializeRowId() function.

See also "Data Types, Variables and Constants"


Accessing Web Properties

Both the client and the server keep track of any changes to the value of a web property. After the first time the value of a web property is changed, its value will be passed to the server with each client call (e.g. during a save request). If a web property is changed during a call to the server, then the changed value is sent back to the client in the call response.

This is the basic mechanism of data synchronization in a web application. Web properties allow the server application to host multiple client sessions simultaneously without the property changes of one client crossing over to the properties of another.

A special syntax (WebGet and WebSet) is used to get and set the value of a web property.

WebGet psValue to sValue


WebSet psValue to sValue

This will get and set the value of the psValue web property of some web object. Only web properties can be used with WebSet or WebGet.


Regular Properties vs. Web Properties

In a web application regular (non-synchronized) property values should be considered static. Only web properties should be changed during the lifetime of the web application (using WebSet).

Changes made to a web property (by the client or via WebSet) do not affect the original property value. The original property value can always be retrieved via a regular Get statement. For example:

{ WebProperty=Client }

Property Integer piCountClick 0

WebGet piCountClick to iSyncValue   // iSyncValue = 0

WebSet piCountClick to 5

WebGet piCountClick to iSyncValue   // iSyncValue = 5

Get piCountClick to iValue          // iValue = 0

Regular property values should only be set inside an object declaration or a class’s Construct_Object method (e.g. Set pbEnabled to False). If they are never changed, then these properties will be equal for each client that makes a call to the server. Setting a regular property value (using the Set command) during a server call can cause “cross contamination” of property values from one client instance to another and should be considered a programming error. Always use web properties (using WebSet\WebGet) for this purpose.

The only time a regular property value can be modified might be to temporarily store some value during a server call. Before the call is finished, you should discard the property value or restore it to its original value. Use this technique with due care.

The WebGet and WebSet commands do not delegate like the normal Get and Set command. If a WebSet or WebGet command cannot find the web-property a runtime error will be declared. Therefore, your object destinations for WebGet or WebSet should either be self or explicitly declared:

WebSet piCountClick of oCustomerView to True


Responsive Web Properties

A web application must adjust to different size clients. Changes in client size can be a one-time thing (e.g. loading on a phone vs loading on an iPad) or it can be dynamic (changing between landscape and portrait mode). The process of making adjustments based on client screen size is referred to as being “responsive”.

Responsiveness is accomplished by using Web Properties that adjusts their value on the client based on the current device size and orientation. The size/orientation specific values are defined by using the WebSetResponsive command.


Web Property Scope

To make web applications more efficient, not every web property value is sent by the client when it makes a call to the server. Only the web properties belonging to objects of the currently active view (and any active modal dialog) are sent, plus the web properties of the global cWebApp object and its local child web objects.

This means, for example, that when the Customer View is the focus when a server call is made, you cannot WebGet properties of the SalesPerson view, because those properties were not sent by the client. Attempting to WebGet a web property that is out of scope will result in an error.

You can, however, WebSet a web property of any valid web object during a server call. This value will be sent back to the client and will replace whatever value was previously stored there.


Web Properties and Unicode

Some web properties are use to store strings that appear on the screen, for example, breadcrumbs in drilldown style web applications. For these strings to contain Unicode characters, the WebAppServerProps table in your workspace, where web properties are stored, must be in a Unicode capable database and format. See Unicode in DataFlex for more information.


Web Property Security

Realize that Web Property values are sent to the client (browser). Even if your Web Property is not displayed in the User Interface it can still be inspected and manipulated by using a client-side debugger.  If you need to store any data that is sensitive and should not be visible to the client-side user then you should consider one of the following solutions:

See Enhanced Security in Web Framework Applications for more information about how ClientProtected Web Properties are used in the framework.

Previous Topic: Confirmations in Web Applications

Next Topic: Web Methods and Events


See Also

Developing Web Applications