<DO/> Defining handling instructions

For each rule, a handling instruction must be defined that functions depending on the previously defined conditions or on the previously determined value. In the handling instruction, the template developer links the results from the value determination with certain actions in the form, such as the selection of an input component or the display of a correction note. In the process, the following is differentiated:

• simple handling instructions that are executed as long as all previously defined conditions are fulfilled and
• validations, whose handling instructions are performed as long as the previously defined conditions are not fulfilled. In contrast with the simple handling instruction, the handling instructions in a validation always refer to a certain input component of the form.

Handling instructions are defined within a <DO/> section. This section must be defined within the tags that determine a restriction level and after the tags that initiate a value determination.

In the process, the following applies for the definition of a handling instruction:

• For each rule, a handling instruction must be defined.
• A handling instruction reacts to the result of the value determination. The instructions within the <DO/> section must match the transferred values from the <WITH/> section (see table).

Examples

Example 1) Displaying or hiding areas of the form dependent on a condition

After the successful authentication, a protected area in the form should be displayed. The form initially shows the editor only a password entry field (st_passwort). When value is entered by the editor, the value entered there from the FirstSpirit framework is compared with the value within a hidden form field (st_master_passwort). if both values are identical, the condition defined within the value determination is fulfilled. The instructions defined within the handling instruction are thus executed. In the form, a component of type CMS_LABEL (st_secret) with the note “Authentication successful” and a component of the type CMS_GROUP (st_secret_group) with “protected content” are displayed. If the passwords are not identical, the second part of the rule definition that shows only the generally accessible content (st_public) comes into effect.

<RULES>

    <!-- show secret area only when current password does match master password -->
    <ON_EVENT>
        <WITH>
            <EQUAL>
                <PROPERTY source="st_master_password" name="VALUE"/>
                <PROPERTY source="st_password" name="VALUE"/>
            </EQUAL>
        </WITH>
        <DO>
            <PROPERTY source="#form.st_secret" name="VISIBLE"/>
            <PROPERTY source="#form.st_secret_group" name="VISIBLE"/>
        </DO>
    </ON_EVENT>

    <!-- show public area only when current password does not match master password -->
    <ON_EVENT>
        <WITH>
            <NOT>
                <EQUAL>
                    <PROPERTY source="st_master_password" name="VALUE"/>
                    <PROPERTY source="st_password" name="VALUE"/>
                </EQUAL>
            </NOT>
        </WITH>
        <DO>
            <PROPERTY source="#form.st_public" name="VISIBLE"/>
        </DO>
    </ON_EVENT>

</RULES>

Additional examples:

• Fill the number of values of an input component depending on the value of a second input component.
• Read and change the value of an input component and assume it in another input component.