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.
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 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 Client
Web Property is sent to the client and can be used by the JavaScript
engine.
Since a property is sent to the server each time an server call is
performed (i.e. each time an action or event is triggered on the server
by the client), it means Web Properties
can be considered persistent data from a given client, server or session
instance. If a web property is changed on the server (using WebSet),
then this changed value is passed back to the client.
Client Web Properties are synchronized to a single client session
(e.g. a single browser tab) while a server call is being processed
from that client. At any other time, Client
Web Properties should be considered out of scope, since there
is no way of knowing to which client session (if any) they are synchronized.
A ClientProtected Web Property is sent to the client, but its value is also stored on the server (like a Server Web Property). Performing a WebGet on these properties will always return the server value. Performing a WebSet will update both the server and the client-side value. The class library uses the ClientProtected properties to perform extra security checks.
A Server
Web Property is attached to the page scope (clears when the
page is reloaded). Its value stays on the server and is not accessible
on the client.
Server Web Properties are not sent to the client and are stored
on the server to provide persistence until the next request from the
client comes in. The goal of Server
Web Properties is to provide an easy and secure method to store
the application state without information being sent to the client.
In addition to security, they can also improve performance when compared
to Client Web Properties.
A ServerSession Web Property is attached to the session (expires together with the session). Its value stays on the server and is not accessible on the client. ServerSession web properties are shared between browser tabs.
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:"
End_Object
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
End_Object
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"
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.
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
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.
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.
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.
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:
Encrypt/Decrypt the Web Property. You would encrypt the web property before performing a WebSet to set its value, and decrypt the property after performing a WebGet to get its value. The drawback of encryption is that encryption can be broken. One way to make this more secure is to calculate and store a checksum for all of your encrypted property values. This makes malicious modification of the encrypted values more difficult.
A safer way to store secure data would be to keep it on the server (do not use Web Properties). You could use a modified version of the WebAppSession table to store secure information for each client session.
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