Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Info

Documentation task

Jira
serverMagnolia
keyDOCU-406

 

Table of Contents

Goal

  • To define new (more logical?) structure of where commands are implemented and defined.
  • Allow easier use of commands by the App developers.
  • Remove command pooling.
  • Get rid of the Commons Chain library (see Greg's comment).

Further (future) goals:

  • Better documentation (list of commands with description, and for each command a list of parameters).
  • Get rid of the Commons Chain library (see Greg's comment).
  • Allow commands to be injected.
  • Allow configuration-by-code for commands.

...

The Previous Status

The above class diagram represents the current distribution of the command classes into the (basic) packages . As we want to get rid of the Admin Interface module, we need to move the MessageCommand class and the whole tree of the BaseRepositoryCommand class to the another package(s).

...

in the releases up to 4.5. 

Implementation

The command classes related to the activation (marked green on the above image) will be were moved to the Activation module (package i.m.module.activation.commands), the rest will be was moved to the Core module, to the i.m.commands.impl package.

The CommandsManager class will be was extended with a method executeCommand(String catalog, String command, Map<String,Object> parameters) , that will allow allows to run commands without need to handle Context etc. The UI classes (actions etc.) should use command by calling this method (i.e. this will be the preferred method, but not the only one).

Command Definitions Reorganisation

The commands are still defined in particular modules, as described in http://documentation.magnolia-cms.com/technical-guide/commands.html - but the catalogs are now additive, i.e. it is possible to define a catalog in one module, and add a new command to the catalog in another module. Anyway, it is still forbidden to have two command of the same name in the catalog - if such situation happens, the CommandsManager will produce RuntimeException on its initialisation.

...

Old pathNew pathNote
/modules/adminInterface/commands/default/activate/modules/activation/commands/default/activate  
/modules/adminInterface/commands/default/deactivate /modules/activation/ commands/default/deactivate  
/modules/adminInterface/commands/website/activate /modules/ui-pages-app/commands/website/activate Composite command, composed of 'version' and 'default-activate' command.
/modules/adminInterface/commands/website/delete /modules/ui-pages-app/commands/website/delete  
/modules/dms/commands/dms/activate /modules/dam-app-assets/commands/dms/activate Composite command, composed of 'version' and 'default-activate' command.
/modules/dms/commands/dms/delete /modules/dam-app-assets/commands/dms/delete  

Remove Command Pooling

The pooling capabilities will be were removed from the MgnlCommand base class, and the CommandsManager will be  has been changed to create new instance for each getCommand() or executeCommand() call.

...

AbstractCommandAction

info.magnolia.ui.modelframework.action.CommandActionBase and AbstractCommandAction and its definition counterpart counterpart info.magnolia.ui.api.action.CommandActionDefinition allows for easy use of commands by the App developers by handling much of the boilerplate code they would otherwise need to write

Todo

Class info.magnolia.ui.framework.app.action.CommandActionBase is replaced by info.magnolia.ui.framework.action.AbstractActionBase.

Jira
serverMagnolia
keyMGNLUI-1290

In most cases it's just a matter of configuration. You define a marker interface extending CommandActionDefinition and bind CommandActionBase to AbstractCommandAction to it. The CommandActionDefinition will need needs to define at least the name of the command to execute, optionally it can define a catalog which otherwisewill use catalog, otherwise it uses the default value, meaning that the command to be executed will be looked for up in the default registered catalog default catalog of commands. Further parameters can be added in the param subfolder and/or my subclassing CommandActionDefinition as the example below illustrates

CommandActionBaseAbstractCommandAction provides a Map<String, Object> buildParams(final Node node) method which builds a map of parameters which will be passed to the current command for execution. It is called by the constructor.

...

 protected Map<String, Object> buildParams(final Node node) {
     Map<String, Object> params = super.buildParams(node);
     params.put(Context.ATTRIBUTE_RECURSIVE, getDefinition().isRecursive());
     return params;
 }

Proposals for future goals (not to be implemented in this sprint):

Getting rid of the Commons Chain library:

New interface Command (a 'copy' of the one from the Commons Chain library) will be defined in the info.magnolia.commands package. (Option: simply remove 'implements Command' from the MgnlCommand class definition.)

The MgnlCatalog class will be rewritten to provide the functionality of the org.apache.commons.chain.impl.CatalogBase class.

This will also require to remove the dependency to org.apache.commons.chain.Context interface from the interface info.magnolia.context.Context, and cross-check for this dependency throughout the code.

Allow commands to be injected

TODO

Allow configuration-by-code for commands

TODO

...