Action definitions configure actions in the UI. The action has a name
which is the name of the definition content node. The action is
identified by this name within a certain scope, such as within a subapp.
Action definitions are used in apps, forms and dialogs. They are
configured and used in the same way throughout the UI. Dialogs and forms
typically require only save and cancel actions, which are simple
configurations.
Action definition properties
Each actions has an action definition class that implements the
ActionDefinition interface.
Some definition classes allow for
additional properties and call further classes to execute logic.
General actions
Example: addContact action definition in
Contacts app. A user can execute
the action in the action bar or in the action popup. When the action is
executed, the detail subapp is launched.
Action definition class that reads the
configuration properties and can supply additional properties to the
action. The class must implement the
ActionDefinition interface.
label
required
Label displayed to users in the action bar or context menu.
implementationClass
optional
The implementation class executes the action. A default implementation
class is typically hard-coded in the definition class. You only need to
add this property if you want to override the default implementation,
for example to perform some extra validation on a saved value.
appName
optional
Name of the app to launch when executing this action. This property
works together with the subAppId property. They tell where the action
takes place. For example, the addContact action takes place in the
detail subapp of the contacts app. The detail subapp displays a form
that allows the user to fill in the contact’s details. Set the property
value to the app name given in
app
configuration.
subAppId
optional
Name of the subapp to open when executing the action.
icon
optional
CSS class that identifies an icon font used on the action. See
Icons.
i18nBasename
optional
Message
bundle such as com.example.apps.messages. You don’t need to set this
property if your message bundle is in the i18n directory inside the
module (best practice). Magnolia will find the bundle automatically.
Only set the property if you put the bundle somewhere else.
dialogName
optional
Dialog to open when the action is executed. A dialog is an alternative
to editing items in an editor. Identify the dialog using syntax
<module name>:<dialog name>, for example pages:editPage. This
property applies only to actions that open dialogs
(OpenCreateDialogActionDefinition and
OpenEditDialogActionDefinition).
nodeType
optional
Node type the action
creates or operates on. This property is needed if the action calls a
dialog. The nodeType property tells the dialog what node type it
should operate on. When the action is executed in a detail app the
property is not needed because the
/browser/contentConnector/nodeType/<node type name>/name property
already defines the node type.
<action definition specific properties>
required/optional
Some action definition classes support
additional properties. For example, ConfirmActionDefinition allows you
to set messages and labels and DownloadBinaryActionDefinition supports
file name and extension properties.
availability
optional
Defines whether the action is permitted on the selected item. See
Action availability.
Commands are used to perform more complicated tasks. For example, the
activate command publishes content from the author instance to public
instances and versions the content.
Each command action used in the UI has its own
action definition class that extends
CommandActionDefinition.
If you want to implement your own command, please create your own
action definition class that extends
CommandActionDefinition.
Please also create your own action implementation class that extends
AbstractCommandAction.
Commands can perform duties within Magnolia or connect to external
resources. A command may be a long-running process. Additional
properties allow you to control whether command actions are run
asynchronously without blocking of the UI.
Example: activate action definition in
Contacts app.
Name of the catalog where the
command resides. You only need this property if you implement a command
that has the same name as an existing command such as activate.
asynchronous
optional, default is false
Runs a command asynchronously in the background. This is useful for
long-running commands. An asynchronous process doesn’t block the UI and
the user can continue to work. To run a command asynchronously, set this
property to true. See also delay and parallel.
notifyUser
optional, default is true
Defines whether the user should be notified in the Notifications app
when an asynchronous action completes. Use together with the
asynchronous property.
timeToWait
optional, default is 5000 milliseconds
Number of milliseconds the UI should remain blocked until the user is
notified that an asynchronous action will complete in the background.
Use together with the asynchronous property.
delay
optional, default is 1 second
Number of seconds to wait before invoking the command. Use together with
the asynchronous property.
parallel
optional, default is true
Defines whether starting multiple instances of the same action in
parallel is allowed. Use together with the asynchronous property.
Useful for preventing the user from starting several long-running
commands. Default allows parallel actions. When you set the property to
false the system will display an error when the user attempts to run
the same action again while the first action is still running.
recursive
optional, default is false
This property is specific to the Publish action. It defines whether the
action can be executed recursively. Set to true to allow recursive
publication.
modifiedOnly
optional, default is false
This property is specific to the Publish action. It publishes only nodes
that are modified or never published. It excludes nodes that are already
published. Use this property to make recursive publishing faster as it
eliminates already-published nodes.
parentNodeTypeOnly
optional, default is false
This property is specific to the Restore previous item action. Set to
true to restore all descendants with the same node type as the parent
node.
Asynchronous actions
Setting the asynchronous property to true allows you to run a
command action asynchronously in the background. Use this feature for
long-running actions that would otherwise block the user interface and
prevent the user from continuing their work.
When a user launches an asynchronous action, Magnolia starts to execute
the action immediately. If the action does not complete in the next five
seconds, the system notifies the user that the action will take a while
to complete. The execution continues in the background while the user
can work on something else. The system informs the user when the action
succeeds or fails. In case of failure a message in the Notifications app
may refer to a log file for more detail.
Publish recursively and Delete action run asynchronously by
default. These actions involve versioning of content and can be time
consuming.
Action definition classes
You can use these common classes in your action definition. They all
implement the ActionDefinition interface.
General actions:
SaveFormActionDefinition
Saves a form.
CancelFormActionDefinition
Cancels a form.
CallbackFormActionDefinition
Executes a callback
SaveDialogActionDefinition
Saves a dialog.
CancelDialogActionDefinition
Cancels a dialog.
SaveConfigDialogActionDefinition
Saves Edit property dialog in the Configuration app.
CreateItemActionDefinition
Opens detail subapp for creating a new item.
EditItemActionDefinition
Opens detail subapp for editing an item.
OpenMoveDialogActionDefinition
Opens the standard Move dialog for an item and its children.
MoveNodeActionDefinition
Moves a node.
CopyContentActionDefinition
Copies a node.
PasteContentActionDefinition
Pastes a node.
RestoreVersionActionDefinition
Restores a previous version.
ShowVersionsActionDefinition
Opens the standard versions dialog.
RestorePreviousVersionActionDefinition
Restores a previous version of an item.
SaveItemPropertyActionDefinition
Saves an item’s property via inplace-editing.
AddFolderActionDefinition
Adds a folder.
AddNodeActionDefinition
Adds a content node.
AddPropertyActionDefinition
Adds a property node.
DeleteItemActionDefinition
Deletes an item.
ConfirmationActionDefinition
Confirms previous action. Used in the confirmation dialog when
deleting.
Activates an item. By default, performs a non-recursive activation.
Used to publish content and deletions.
DeactivationActionDefinition
Deactivates an item.
MarkNodeAsDeletedActionDefinition
Marks a node as deleted. Uses markAsDeleted command
ExportActionDefinition
Exports an item and its children to XML.
ExportYamlActionDefinition
Exports a YAML file.
DownloadBinaryActionDefinition
Downloads a binary node such as an image. Available properties:
binaryNodeName, dataProperty, fileNameProperty and
extensionProperty.
ZipUploadActionDefinition
Imports a ZIP file. Uses importAssetZip command.
SaveImportDialogActionDefinition
Saves Import dialog that imports XMLs. Uses import command.
RestoreItemPreviousVersionActionDefinition
Restores a previous version. Uses restorePreviousVersion command .
Set parentNodeType to true to restore descendants with same node
type as parent .
Reusing an action
Reuse the existing Magnolia actions in your own app. Many actions are so
basic that you can just copy the action definition. Some actions have
their own properties. You may need to set them for the action to work.
Example: The DownloadBinaryActionDefinition allows you to download a
binary node from the repository to your computer. This action is
available in the Assets app by default where the user can download
images from the dam workspace. In this example, we use the same action
in the Contacts app to download a contact photo.
Action availability defines whether the action is permitted on the
selected item. For example, the addCategory action below is permitted
when:
The selected item is a category, meaning you can create subcategories.
The selected item is a folder.
At the root level of the workspace, meaning you can create a category
without selecting an item.
The selected item is not marked for deletion.
You can add multiple availability rule classes. See the
example below. The rules parent node contains subnodes, one for each
rule. The rules are combined with a logical AND operator. Each rule must
have the implementationClass property which points directly to the
rule class.
Action is available if the selected item(s) match every availability
rule class
<ruleNodeName>
required
Give the node a name that describes the rule class
implementationClass
required
Availability rule class name. Class must implement
info.magnolia.ui.api.availability.AvailabilityRule (usually you can
extend info.magnolia.ui.api.availability.AbstractAvailabilityRule)
nodes
optional, default is true
Action is available if the selected item is a node.
root
optional, default is false
Action is available at the workspace root level if true.
properties
optional, default is false
Action is available if the selected item is a property.
multiple
optional, default is false
Boolean property that enables and disables multiselection. Available
when the action class extends AbstractMultiItemAction.
writePermissionRequired
optional, default is false
Set to true if the action requires write permission on the currently
selected node. The action will be disabled if the user doesn’t have
write permission.
Action availability is different from
action
bar section availability. Section availability defines whether the
actions configured within a section are displayed in the action bar. If
the section is displayed, then action availability is checked for each
action in the section.
Action availability definition classes
IsDeletedRule
Returns true if the item is node and has mgnl:deleted mixin
type.
IsNotDeletedRule
Returns true if the item is not a node, or if it is a node and does
not have mgnl:deleted mixin
type.
HasVersionsRule
Returns true if versioning is enabled for an item and the item has
versions.
IsNotVersionedRule
Returns true if versioning is not enabled for an item.
IsPublishableRule
Returns true if all ancestors of the item are activated.
IsPublishedRule
Returns true if a node’s ActivationStatus is not
ACTIVATION_STATUS_NOT_ACTIVATED.
IsDefinitionRule
Returns true if the item has a DefinitionProvider.
IsNotVersionedDetailLocationRule
Returns true if the current DetailLocation is not versioned.
Actions on multiple items
Action availability defines whether an action can be executed on
multiple items. Delete, move, publish and unpublish are examples of
actions that can be executed on multiple items. Actions that extend
AbstractMultiItemAction can handle multiple items. By default, the
delete action is available for multiple items in all content apps.
Defines whether the action is available for multiple items.
To do a more detailed availability check, such as to verify that all the
items are on the same level or have the same parent, use
action availability rules.
When you program an action that supports multiple items you are
responsible for handling the items in the correct order and solving
dependencies. For example, when deleting multiple nodes where one node
is a child of another, delete the nodes in a correct order to avoid
exceptions, or handle such exceptions. An action is also responsible for
informing the user about the result, whether it has successfully
processed all the items or failed on some of them.