[
https://issues.apache.org/jira/browse/ISIS-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15282690#comment-15282690
]
ASF subversion and git services commented on ISIS-1291:
-------------------------------------------------------
Commit 7ebbb70c115636f872d13bb1c367916febc961c3 in isis's branch
refs/heads/ISIS-1291 from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=7ebbb70 ]
ISIS-1291: documentation on command and events.
Also:
- adding missing schemas in adocs documentation (for hosting on the web).
- updating bad links to @Xxx_aaa in multiple files
- deprecating some methods in applib API.
> 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
> Labels: implemented
> 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)
