First level of rule definition

<RULES/>

Top level of rule definition:
starts a rule definition. Within a rule definition, any number of rules can be defined for a form, whereby each rule commences from a restriction level and must always contain at least one value determination and one handling instruction.
(More ...)

None

Second level of rule definition - selection of a restriction level

SAVE

Highest restriction level: rule violations within this restriction level prevent the saving of the form by the editor. Color scheme for messages from the FirstSpirit framework: berry.
(More ...)

None

RELEASE

Medium restriction level: rule violations within this restriction level permit the saving of the form by the editor, but a release of the content is not possible. Color scheme: orange/yellow.
(More ...)

None

INFO

Lowest restriction level: rule violations within this restriction level permit the saving of the form and the release of the content by the editor. Color scheme: no highlighting of the rule violation.
(More ...)

None

Third level of rule definition - within a restriction level

<IF/>

Initiates the definition of an (optional) precondition. The definition of a precondition must take place within a restriction level and before the tags for value determination and handling instruction. The following sections of the rule (value determination, handling instruction, validation) are performed only if the precondition is fulfilled. The specification of additional tags is necessary within the precondition.
(More ...)

None

<WITH/>

Initiates a value determination. The value determination must take place within a restriction level after the definition of an (optional) precondition and before the tags for the handling instruction. The result of the value determination is evaluated in the subsequent sections of the rule (handling instruction and validation). Within the value determination, the specification of additional tags is necessary.
(More ...)

None

<SCHEDULE/>

Initiates the asynchronous execution of a rule. In the process, the <SCHEDULE/> tag is used to transfer the value determination from SiteArchitect to a FirstSpirit module.
Prerequisite: the corresponding module must previously be installed on the server.
The asynchronous value determination must take place within a restriction level and before the tags of the handling instruction. The specification of additional tags is necessary within the value determination. Optionally a condition that initiates or inhibits an execution of the value determination via the module can be defined using the <CONDITION/> tag. In addition, parameters can be sent to the module through one or more <PARAM/> tags, for example, the values from an input component of the form. After the execution of the asynchronous value determination, the handling instruction is executed with the return value determined by the module.
(More ...)

service: name of the module

id: additional specification of an abbreviation for a clear design of the validation requests of various forms to the module.

delay: (optional) specification of a waiting period in milliseconds. Without specification, a value of 0 is assumed. If a value greater than 0 is specified, the execution of the validation on the module is delayed by the corresponding time.

<DO/>

Initiates a handling instruction. The handling instruction must take place within a restriction level and according to the definition of an (optional) precondition and a value determination. The result of the value determination is evaluated in this section.
In the process, the following applies: if the conditions defined previously in the value determination are fulfilled, the instructions within the <DO/> section are executed.
Special case: the <VALIDATION/> section is executed within the <DO/> section as long as the conditions defined in the value determination are not fulfilled (i.e. as long as the value determination returns FALSE).
Within the handling instruction, the specification of additional tags is necessary.
(More ...)

None

Fourth level of rule definition - within a handling instruction

<VALIDATION/>

Initiates a validation. The validation must take place within a handling instruction. The validation always refers to a certain property of the form or an input component that is checked within the value determination. The validity of this property is checked during the validation. For this purpose, the specification of a <PROPERTY/> tag with the VALID is necessary. All subsequent handling instructions within the validation section are then executed as long as the conditions defined in the value determination are not fulfilled (e.g. as long as the value determination returns FALSE).
(More ...).

None

Internal tags for value determination or the output of correction notes:

<MESSAGE/>

Use for the definition of language-dependent notes that are displayed directly below the corresponding input component in the form in case of a rule violation. The rule can be used within the validation.
(More ...)

long: specification of a language abbreviation to be entered in the "Abbreviation" field in the server properties to define for which project language the definitions should apply. Alternatively, an asterisk (*) can be used for fallback values.

text: specification of a language-dependent note.

<PROPERTY/>

The tag can be used in all rule definition areas to evaluate the properties of an input component or general information for a form (e.g., is the input component empty?) or to define properties for an input or design component (e.g., input components should be hidden in the form).
(More ...)

source: name of an input or design component or #global (More ...)

name: specification of the property
(More ...)

<MATCHES/>

Used to define a regular expression. The regular expression is transferred via the regex parameter. In addition to the regular expression, a comparison value must be specified through an internal <PROPERTY/> tag. The tag can be set within the value determination (or during the definition of a precondition).
(More ...)

Attention: only possible simple values (e.g., from CMS_INPUT_TEXT), not for more complex values (e.g., from CMS_INPUT_DOM).

regex: specification of the regular expression

<EQUAL/>

Used for the comparison of values. The tag can be used within the value determination (or during the definition of a precondition). Within the tag, at least two values must be specified for comparison.
(More ...)

None

<GREATER_THAN/>

Used for the "greater than" check of a numeric value with a comparison value. The tag can be used within the value determination (or during the definition of a precondition). Within the tag, at least two values must be specified for comparison.
(More ...)

None

<LESS_THAN/>

Used for the "less than" check of a numeric value with a comparison value. The tag can be used within the value determination (or during the definition of a precondition). Within the tag, at least two values must be specified for comparison.
(More ...)

None

<NOT_NULL/>

Checks whether an input components contains a value (TRUE) or not (FALSE). The tag can be used within the value determination (or during the definition of a precondition). The check always refers to the value of an input component. In addition, the specification of a <PROPERTY/> tag with the VALUE attribute within the tag is necessary.
(More ...)

None

<IN_GROUP/>

This is used to check to which group the editor belongs. The tag can be used within the value determination (or during the definition of a precondition).
(More ...)

name: name of the group

<AND/>

Used for the logical AND operation of several conditions within the value determination or during the definition of a precondition. If several conditions are linked using <AND/>, the compound expression is true precisely when all linked expressions are true.
(More ...)

None

<OR/>

Used for the logical OR operation of several conditions within the value determination or during the definition of a precondition. If several conditions are linked using <AND/>, the compound expression is true precisely when at least one of the linked expressions is true.
(More ...)

None

<NOT/>

Negation of a condition within the value determination or during the definition of a precondition.
(More...)

None

<ADD/>

Used to calculate with values in dynamic formulas. The tag can be used within the value determination, for example, to add whole numbers to an existing value or to add a defined period of time to an existing date.
(More ...)

value: using the attribute, a whole number or time unit can be transferred, separated by a space character. (More ...)

Internal tags for the transfer of constants

<DATE/>

Serves for indicating a constant date within a check for equality (<EQUAL/>), greater than (<GREATER_THAN/>) or less than (<LESS_THAN/>).

A date can be defined by using the following schema:
<DATE>Date Time Zone</DATE>
Example:
<DATE>2012-12-01 00:00:00 +0100</DATE>

Formatting definitions:
Date has the format: jjjj-mm-dd with
jjjj = year, mm = number of month, dd = day in month
(Example: 2011-12-15)
Time has the format: hh:mm:ss with
hh = hour, mm = minute, ss = second
(Example: 14:18:23)
Zone has the format: +zzzz or -zzzz with zzzz = difference, indicated in format hour-minute in comparison to UTC
(Example: +0100) Differences concerning daylight savings time must be considered.

Possible combinations:
1) Date Time Zone
2) Date Zone - Time is set then to 00:00:00
3) Time Zone - Date is set then to 01.01.1970 (in analogy to the date component)
4) each without giving the Zone - in this case, the time zone which exist in SiteArchitect when the rules are evaluated.

Note:
Date and time will be stored as UTC in the combination Date Time, but they are displayed in the local time zone in SiteArchitect. In this case, no offset should be specified in the rule definition.
(More ...)

None

<NUMBER/>

Used to specify a numeric constant within a check for equality(<EQUAL/>), greater than (<GREATER_THAN/>), or less than (<LESS_THAN/>).
(More ...)

None

<TEXT/>

Serves for specifying textual constant within a check for equality (<EQUAL/>).
(More ...)

None

Internal tags for the transfer of information to a FirstSpirit module

<CONDITION/>

Initiates the definition of an (optional) precondition for the asynchronous execution of a rule. The definition of a precondition must take place within a <SCHEDULE/> tag and before the tags for the handling instruction. The following sections of the rule (value determination through an external module, handling instruction, validation) are performed only if the precondition is fulfilled. The specification of additional tags is necessary within the precondition.
(More ...)

None

<PARAM/>

Transfer of parameters to a FirstSpirit module. If the value determination is transferred from SiteArchitect to a FirstSpirit module, parameters can be sent to the corresponding module within a <SCHEDULE/> tag, for example, the current values from an input component of the form. The specification of additional tags is necessary within a <PARAM/> tag.
(More ...)

name: name of the parameter