skip to main content

Class warnings

A class warning is a validation rule based on a boolean expression: when the condition defined by the expression occurs, it is possible to prevent the user's action or show a simple warning.

A Class warning consists of a unique name, a condition (the Boolean expression) and a message that is shown when the condition is met. In case the Designer prevents the creation or modification of an object of a class it is called a blocking Class warning .

Create a Class warning #

From the Application Schema , right click on a class to open its Class menu and select Set warnings... to open the Class warnings manager. Click on Add to open the Class warnings editor.

Alternatively, click on the icon in the class footer and click Add to open the Class warning editor.

Create a Class warning

To remove all declared Class warnings (without removing them individually from the editor) simply right-click on the in the class footer and select the Delete warnings option.
Delete all Class warnings

Class warnings manager #

The Class warnings manager is the manager of the Class warnings defined for a given class. Through the Add, Edit and Delete buttons you can add, edit or delete a Class warning. The option Copy warnings to other applications allows to extend all warnings to other application views, which can be selected through the respective checkboxes from the contextual panel (Link to other applications).

Blocking Class warnings are highlighted in orange, while non-blocking ones are highlighted in green.

Class warnings manager

Class warnings manager

The example in the figure shows the Class warnings manager of the Product_batch_component class: two Class warnings have been added, one blocking (insufficientQuantity) and one non-blocking (endDateInPast).

Class warning editor #

The Class warning editor

Class warning editor

The Condition field of the Class warning editor contains within it an Expression editor, in which you can type an expression, which must necessarily be a Boolean condition. When the expression is recognized as valid, the editor displays the message Validated as BOOLEAN.

Depending on the configuration of the checkboxes in the Evaluated on section, the editor determines at what time to evaluate the condition:

  • Create: when the Create button is pressed;
  • Open: when the Open button is pressed;
  • Edit: when the Edit button is pressed;
  • SaveNew: when a new object is saved for the first time;
  • SaveExisting: when changes to a pre-existing object are saved;
  • Delete: when an object is deleted.

Finally, in the Message section you can define the warning that is shown when the condition occurs: Checking the Block action when message is displayed option, you can decide to block the user’s action when the message is shown; this can be useful to prevent users from making changes that would introduce inconsistencies in the application.

An example of a Class warning within the Web Client

An example of a Class warning within the Web Client

Example #

In the next example, the Employee class is used to store data about employees hired by a company. The date_joined attribute represents the date of hire, while /age is a derived that calculates the age of the employee based on the date of birth (date_of_birth).

Example: the Employee class with no class warning

The Employee class, still with no Class warning

There are currently two cases that could result in inconsistencies in the data:

  • by filling in the date_joined field you can enter any date, even a future date;
  • the /age attribute can have a value less than 20; an employee under 20 is too young to be hired.

It is clear that in order to avoid these two scenarios we cannot proceed narrowing down the domain of attributes at the Database schema level, because this would only allow us to statically define minimum and maximum values for date_joined and date_of_birth (/age is a math computed on another attribute, and thus no domain restriction can be imposed on it directly); we would thus be forced to continuously update the application at database level.

The most appropriate way to proceed is to model these restrictions at the application level, through Class warnings:

  • joinedInFuture checks that the assumed date (date_joined) is earlier than the current date (__System.date); the expression used is therefore date_joined > __System.date.
  • under20 appears when the /age attribute takes a value less than 20; the condition is therefore age < 20.

We made both warnings blocking, so as to prevent incorrect data from being entered into the application when saving and editing class objects (by checking the SaveNew and SaveExisting options).

Class warnings manager

A third Class warning was added to warn the user if the employee’s salary (hourly_cost) is too low by comparing the figure entered with an appropriate reference to the years of seniority accrued in the company. For this purpose we have inserted in the Class warning editor the following expression: hourly_cost < (25 + dateDiff(__System.date, date_joined, field.year) * 10); the warning appears when the salary is less than 25 plus the years spent in the company (calculated by subtracting the year field of date_joined from the year of the current date __System.date), all multiplied by 10. In this case we have not made the warning blocking, but we have added a simple warning, writing in the dedicated box the message “Hourly cost is too low with respect to the employee’s experience”, as shown in the figure.

The Class warning editor for lowCost

The Class warning editor for lowCost