EDITABLE property
Blocking and unblocking input components for editing
An input component can have the ability to edit values and save persistently. The expression <PROPERTY source="gadget" name="EDITABLE"/> can be used in the handling instruction area of the rule definition, and allows the editing of input components in the form (depending on a certain condition).
With the help of the attribute EDITABLE, for example, a rule can be defined that enables the editing of an input component, depending on the editing language or the store type in which the form is opened.
Examples
Example 1) Editing depending on the value of a different input component
In a form, there is an input component “st_picture” and an input component “st_description”. It should be ensured via a dynamic form that the input component “st_description” can only be edited if the input component “st_picture” is not empty.
Within the <WITH/> section, it will first be checked via a <PROPERTY/> tag whether the input component “st_picture” is not empty. The result of this check is a Boolean value, which is then linked in the <DO/> section with a handling instruction. If the condition is fulfilled (value determination returns TRUE), the input component “st_description” is set to “editable” via an additional <PROPERTY/> tag. If the condition is not fulfilled (“st_picture” is empty and the value determination returns FALSE), the input component “st_description” cannot be edited in the form.
<RULES>
<ON_EVENT>
<WITH>
<NOT><PROPERTY source='st_picture' name='EMPTY'/></NOT>
</WITH>
<DO>
<PROPERTY source='st_description' name='EDITABLE'/>
</DO>
</ON_EVENT>
</RULES>
Note: This definition is not necessarily suitable for being edited with InEdit. See also page Display of rule violations in ContentCreator.
Example 2) Editing depending on the affiliation of the editor with an editing group
In a form, there is an area (CMS_GROUP) with multiple input components. Via a dynamic form, it is to be ensured that this area is only editable by editors who are members of the editing group “editors”.
Within the <WITH/> section, first the editor's group membership is determined with the tag <IN_GROUP/> and compared with the name of the group defined there. The result of this check is a Boolean value, which is then linked with a handling instruction in the <DO/> section. As long as the condition (“Editor is a member of the editor group”) is fulfilled, the form area “group_editors” can be edited.
<RULES>
<ON_EVENT>
<WITH>
<IN_GROUP name="editors"/>
</WITH>
<DO>
<PROPERTY source='#form.group_editors' name='EDITABLE'/>
</DO>
</ON_EVENT>
</RULES>
Example 3) Preventing manual editing of input components (setting a value using a script)
In a form, there is one “rules_text” input component. Via a dynamic form, it is to be ensured that the “rules_text” input component cannot be edited manually by the editor.
Within the <WITH/> section, the input component is first permanently prevented from being edited using the <FALSE/> constant.
<RULES>
<ON_EVENT>
<WITH>
<FALSE/>
</WITH>
<DO>
<PROPERTY name="EDITABLE" source="rules_text"/>
</DO>
</ON_EVENT>
</RULES>
Instead of editing the value manually, the value of the input component should be set here using a script. An additional “rules_button” input component of the type FS_BUTTON is stored in the form for this purpose. Clicking the “rules_button” executes the “set_value” BeanShell script, which automatically writes a value to the “st_text” input component.
Form:
...
<FS_BUTTON name="rules_button" noBreak="yes" onClick="script:set_value">
<LANGINFOS>
<LANGINFO lang="*" label="Set"/>
</LANGINFOS>
<PARAMS>
<PARAM name="target">#field.rules_text</PARAM>
</PARAMS>
</FS_BUTTON>
<CMS_INPUT_TEXT name="rules_text">
<LANGINFOS>
<LANGINFO lang="*" label="rules"/>
</LANGINFOS>
</CMS_INPUT_TEXT>
...