Details
-
New Feature
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.11.0
Description
A command is NOT an action invocation, it is an INTENTION to invoke an action. Generally that intention is carried out immediately, hence a foreground command. Sometimes though it is carried out in the background, so is a deferred intention.
What this implies is that a command should not contain details of the action's results. (If that information is available from reified ActionDomainEvents, then they can be contributed/mixed in)
A command should cope with the concept of being invoked on more than one object, ie having a list of targets. nb: this implies that our current terminology of "bulk actions" is actually wrong, we ought to be talking about "bulk commands".
We can envisage (at least) two different user intentions when performing a bulk command:
a) perform the operation on as many as possible, or
b) perform the operation on all of them, or none at all.
The former suggests that each action is wrapped in its own command: the user intends to operate on each object, one after the other. The latter suggests that all the actions live in a single command.
Dan's view is that a command is one:one with a (DB) transaction.
~~~
the original version of this ticket was to change the Command#setMemento to use the ActionInvocationMementoDto. However, that now seems to be incorrect:
- an AimDto is a record of an action being invoked (past tense, if you will), not the intention to invoke an action
- as such an AimDto holds a return value, but that is strictly irrelevant to a Command
- an AimDto relates only to a single target, whereas a Command could have multiple targets ("perform this action on all of em, or none of em")
So, instead, this ticket is to define a new XSD just as the reified form of Commands. It needs to be able to handle mxins, and bulk actions. It shouldn't have action results.
~~~
Note that this will also require some data migration scripts for anyone that has used this feature.