[ https://issues.apache.org/jira/browse/ISIS-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15282948#comment-15282948 ]
ASF subversion and git services commented on ISIS-1291: ------------------------------------------------------- Commit 7ebbb70c115636f872d13bb1c367916febc961c3 in isis's branch refs/heads/master 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)