A dialog definition consists of
form subnodes. It is a very simple definition. The actual work is done in the form and action definitions which determine what content users can enter into the dialog and how to submit it. The class that reads the definition and configures the dialog is
. You can configure your own dialogs in the
/dialogs folder of your module.
This example dialog edits content in a Text & Image component. You can find the definition in Configuration >
actions: Contains action definitions which define how the data is submitted. The actions are rendered to users as buttons. Typically you need at least Save and Cancel actions.
form: Contains a form definition which defines the fields where content is entered.
extends: (property) Extends another dialog definition. Set the value to a relative or absolute path that points to the extended dialog definition. Optional.
modalityLevel: Modality level defines how intrusive the dialog is. Valid values are
actionArea: Optional; it allows to define secondary actions. (see below for more details.)
See also: Referencing a dialog definition
The actionArea lets you provide additional actions and to specify a renderer if required. You need a renderer when the action requires more then just a button (for instance for an upload action).
Let's have a look at the chooseDialog of the assets subapp of the dam module. The root node of the configuration snippet below is
secondaryActions: Add subnodes which must have the same name like actions which you have defined in the
actionsnode. The order of the subnodes defines the sequence in which they are rendered.
actionRenderers: Define a subnode for each action which requires its own renderer.
rendererClass: The class of the specific renderer which must implement ActionRenderer