Start page / Template development / Rules

Rules – Creating dynamic forms

Contents

A template developer can defined rules within the (form) template that affect certain elements or properties of the form and in so doing create a “dynamic form”. Rules can be used wherever FirstSpirit forms are used and indeed in both SiteArchitect and in ContentCreator, e.g., in:

  • Forms for the page store and content store
  • Metadata forms
  • Forms for workflows
  • Forms for scripts
  • Forms for link templates

Dynamic forms are used to:

  • Detect invalid states in the content of forms. It is possible to check, for example, whether a date is in the future (e.g., deadlines that have not yet arrived) or the past (e.g, press releases) based on the requirement of the corresponding input component
  • Hide individual form fields in a form under certain conditions. This makes it possible, for example, to prevent certain user groups from displaying and editing content or to only allow specific fields to be edited in certain stores
  • Establish logical relationships between form elements which automatically generate changes in a dependent field. Selecting one of two suppliers in a checkbox, for example, can affect a dependent combo box which will only list certain products based on the supplier selected

The rules on the corresponding form element can be analyzed at various stages of the editorial work process:

  • directly during editorial work (with every input)
  • when saving or
  • when switching to edit mode or creating a new element

(See also <RULE/> tag.)

A rule violation (<VALIDATION/> tag) is displayed in a uniform manner for all elements. Of course, the display is clearly different from the usual layout of the workspace so that incorrect inputs are obvious. As well as color-coding dependent on the underlying restriction level, the display also includes text in the relevant language explaining why the state is invalid. The creator of the dynamic form (i.e., the template developer) can then decide how to proceed with the editing of elements in this state (whether they are to be taken into account during a generation run, for example).

Important Available from FirstSpirit Version 5.2 The syntax for the definition of rules was modified in FirstSpirit version 5.2. Existing rule definitions from earlier versions of FirstSpirit continue to be valid in FirstSpirit version 5.2 and are interpreted accordingly. However, there will come a point in time when the old syntax will be invalid and support for it will cease. Therefore, the new syntax should be adopted as early as possible. See also the Migration page.

Note: You can use the option “Validate language” within the properties of the desired project in FirstSpirit ServerManager in the “Languages” area to deactivate the validation for single languages. See also Languages (→Documentation for Administrators).

Supplements to this document

Examples

FirstSpirit API

Access API documentation:

  • Interface SaveOperation
    This interface can be used to save store elements and datasets programmatically. Saving an element or dataset may be carried out even if the object to be saved contains erroneous or invalid data, e.g. due to a rule infraction, by using the method setValidationEnabled(false).
  • Interface Language
    You can use the methods setIgnoreValidation() to define if validation should be used for a language or not.
  • Interface ValidationAgent
    This interface provides access to functions to validate the data in the form against the rules defined in it. This validity status is needed in workflows, for example, to check whether an element can be released.

Restrictions

Important Using rules to display and hide form elements is not a security model for protecting data and content from unauthorized access. The rules only serve to make forms easier to read and assist in editorial work.

Validation of referenced datasets in FS_INDEX

For input components that reference and display datasets, general validation of all internal objects is not always desirable either from an editorial point of view or for performance reasons.

For validation of an FS_INDEX input component, the following applies:

  • Errors caused by rule violations in referenced datasets are no longer taken into account in the input if the corresponding subform is not visible However, a rule violation in a referenced dataset will not prevent the entire form from being saved or released. This procedure only affects associated datasets.

© 2005 - 2024 Crownpeak Technology GmbH | All rights reserved. | FirstSpirit 2024.3 | Data privacy