To continue with this content, please log in with your Data Access ID or create a new account.
Cancel Data Access ID
You may not be authorized to see this content. Please contact Data Access Europe for more information.
Cancel Data Access Europe
You are not authorized to see this content.
Cancel Data Access Europe
Next lesson:
Adding your own Web Properties
Cancel

Web Properties

Lesson 1: Basics and usage

What are Web Properties?

Web properties are very similar to regular properties with the addition that the value is retrieved from the client with each server call. 

There are multiple ways this can be achieved, and which depends on the type of web property being used. There are three types of web properties:

  1. Client
  2. Server
  3. ServerSession


What are Web Properties used for?

Web properties are used for configuring the UI, communicating the UI at the client, and storing data and application states.


Why are Web Properties needed?

These properties are the solution for a webapp server problem known as process pooling. This is when each call from the client to the server is potentially handled by a different process. The webapp server has no memory of any previous calls. It is essentially state-less. There is no persistency on the server, which means that if a value is set in a call it may not be retrieved again in a future call. Web Properties, using WebGet and WebSet, are the solution for this. 

For any Web Property regular Get and Set calls can be used for the initial value up until the OnLoad event. If the value needs to be called or set at the runtime WebGet and WebSet are used.

Client Web Properties are slightly different. They are sent to the client upon WebApp initialization, and the first time the WebSet is used for the Client WebProperty it becomes synchronized. This means the value can be sent back-and-forth with each call.

Web properties also adhere to responsive rules. The value can be changed based on the current window size. This is done using WebSetResponsive. Several modes can be chosen to do this, but the most common modes are rmDesktop, rmTablet and rmMobile. 


Demonstration

  1. Shown is a very simple WebApp that has a web label and several buttons that will manipulate the label. The names of the buttons indicate what action is being used.
  2. The code shows the default value…
  3. … followed by all the buttons with their various actions: set, WebSet, getWebGet, etc.
  4. A ‘Get’ returns the initial value.
  5. A ‘WebGet’ returns the current value, which at this time is same as the initial value.
  6. Clicking ‘Set’ causes a set on the server, but it will not be scoped to the session. This may cause process pooling when ‘Get’ or ‘WebGet’ are selected repeatedly. For example, selecting ‘Get’ twice more brought up two different results; the initial default value, and then a different message, “Set value!”
  7. This shows that different processes are being used causing varying results. Using ‘WebSet’ and ‘WebGet’ together fixes the issue. Clicking ‘WebSet’ first sets a new value for the label (WebSet value!), and then regardless of how many times ‘WebGet’ is pushed the same value will be returned.