[
https://issues.apache.org/jira/browse/ISIS-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood updated ISIS-1291:
------------------------------
Fix Version/s: (was: 1.14.0)
1.13.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.
was:
Note that this will also require some data migration scripts for anyone that
has used this feature.
We should however be clear about this: conceptually the Command is an intention
to invoke an action, it isn't the record of the action being invoked. That,
instead, is the domain event (if in-memory) or its reified form, ie the
ActionInvocationMementoDto, intended for use when publishing.
Summary: Define new DTO (XSD) as the memento for Command#setMemento
(was: Use Isis' action invocation memento DTO (XSD) schema for the
Command#setMemento())
> Define new DTO (XSD) as the memento for Command#setMemento
> ----------------------------------------------------------
>
> Key: ISIS-1291
> URL: https://issues.apache.org/jira/browse/ISIS-1291
> Project: Isis
> Issue Type: New Feature
> Components: Core
> Affects Versions: 1.11.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: 1.13.0
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
