[
https://issues.apache.org/jira/browse/ISIS-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333548#comment-15333548
]
ASF subversion and git services commented on ISIS-1291:
-------------------------------------------------------
Commit e2e206c3e5e4e21a9c19864bef7417aacfe58945 in isis's branch
refs/heads/master from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=e2e206c ]
ISIS-1291: adds @Programmatic where necessary for new and internal domain
services
... so that this stuff isn't unnecessarily loaded into themetamodel.
In a similar vein, aAlso change IsisConfiguration so that it doesn't implement
Iterable, because otherwise the default interface methods (spliterator,
forEach) show up in the metamodel. Instead, extend to provide an
"asIterable()" method.
> 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)
