[jira] [Updated] (ISIS-1228) Introduce nextTransaction() into fixture scripts. Generalized to reorganizing/splitting out DomainObjectContainer service.
[ https://issues.apache.org/jira/browse/ISIS-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood updated ISIS-1228: -- Summary: Introduce nextTransaction() into fixture scripts. Generalized to reorganizing/splitting out DomainObjectContainer service. (was: Introduce nextTransaction() into fixture scripts.) > Introduce nextTransaction() into fixture scripts. Generalized to > reorganizing/splitting out DomainObjectContainer service. > --- > > Key: ISIS-1228 > URL: https://issues.apache.org/jira/browse/ISIS-1228 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: core-1.8.0 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: 1.12.0 > > > originally raised by Oscar: > When using FixtureScripts, there can be many actions that, on the real world, > are execute in different time contexts. > For example, a user creates an Account on the webapp and after that executes > different actions. > That’s relevant if using the queryResultsCache service (or the new planned > “@Action” annotation extension) because the results previously created (i.e., > the Account) might be available on the cache. > So perhaps some mechanism like the nextTransation() method might be also > introduced on FixtureScripts. > What do you think? > ~~~ > Dan's reply: > Makes sense. > There is a nextTransaction() method in the AbstractIntegTest class, you could > see how that is implemented and see if it can be adapted? > Or, another idea is that the framework could run each FixtureScript > automatically in a separate transaction; that would be a better simulation of > a sequence of user interactions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ISIS-1228) Introduce nextTransaction() into fixture scripts. Generalized to reorganizing/splitting out DomainObjectContainer service.
[ https://issues.apache.org/jira/browse/ISIS-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood resolved ISIS-1228. --- Resolution: Fixed > Introduce nextTransaction() into fixture scripts. Generalized to > reorganizing/splitting out DomainObjectContainer service. > --- > > Key: ISIS-1228 > URL: https://issues.apache.org/jira/browse/ISIS-1228 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: core-1.8.0 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: 1.12.0 > > > originally raised by Oscar: > When using FixtureScripts, there can be many actions that, on the real world, > are execute in different time contexts. > For example, a user creates an Account on the webapp and after that executes > different actions. > That’s relevant if using the queryResultsCache service (or the new planned > “@Action” annotation extension) because the results previously created (i.e., > the Account) might be available on the cache. > So perhaps some mechanism like the nextTransation() method might be also > introduced on FixtureScripts. > What do you think? > ~~~ > Dan's reply: > Makes sense. > There is a nextTransaction() method in the AbstractIntegTest class, you could > see how that is implemented and see if it can be adapted? > Or, another idea is that the framework could run each FixtureScript > automatically in a separate transaction; that would be a better simulation of > a sequence of user interactions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1228) Introduce nextTransaction() into fixture scripts.
[ https://issues.apache.org/jira/browse/ISIS-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15192481#comment-15192481 ] ASF subversion and git services commented on ISIS-1228: --- Commit c21c22c730b9d70f332cec19021f0bfa7039e094 in isis's branch refs/heads/master from [~danhaywood] [ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=c21c22c ] ISIS-1228: updating docs. > Introduce nextTransaction() into fixture scripts. > - > > Key: ISIS-1228 > URL: https://issues.apache.org/jira/browse/ISIS-1228 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: core-1.8.0 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: 1.12.0 > > > originally raised by Oscar: > When using FixtureScripts, there can be many actions that, on the real world, > are execute in different time contexts. > For example, a user creates an Account on the webapp and after that executes > different actions. > That’s relevant if using the queryResultsCache service (or the new planned > “@Action” annotation extension) because the results previously created (i.e., > the Account) might be available on the cache. > So perhaps some mechanism like the nextTransation() method might be also > introduced on FixtureScripts. > What do you think? > ~~~ > Dan's reply: > Makes sense. > There is a nextTransaction() method in the AbstractIntegTest class, you could > see how that is implemented and see if it can be adapted? > Or, another idea is that the framework could run each FixtureScript > automatically in a separate transaction; that would be a better simulation of > a sequence of user interactions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1318) contributed actions/mixins breaks publishing.
[ https://issues.apache.org/jira/browse/ISIS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15192478#comment-15192478 ] ASF subversion and git services commented on ISIS-1318: --- Commit 8d2a0626336179ccf52b797ec4c7f991a1d05a47 in isis's branch refs/heads/master from [~jcvanderwal] [ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=8d2a062 ] ISIS-1318: further fix to allow publishing of wrapped actions previously was using the action identifier obtained from the command, however the command only ever holds the details of the outermost action. > contributed actions/mixins breaks publishing. > - > > Key: ISIS-1318 > URL: https://issues.apache.org/jira/browse/ISIS-1318 > Project: Isis > Issue Type: Bug > Components: Core >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1228) Introduce nextTransaction() into fixture scripts.
[ https://issues.apache.org/jira/browse/ISIS-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15192480#comment-15192480 ] ASF subversion and git services commented on ISIS-1228: --- Commit 387fe368f0eb909334280e8bab657e255daf764f in isis's branch refs/heads/master from [~danhaywood] [ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=387fe36 ] ISIS-1228: breaking out new domain services from DomainObjectContainer. > Introduce nextTransaction() into fixture scripts. > - > > Key: ISIS-1228 > URL: https://issues.apache.org/jira/browse/ISIS-1228 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: core-1.8.0 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: 1.12.0 > > > originally raised by Oscar: > When using FixtureScripts, there can be many actions that, on the real world, > are execute in different time contexts. > For example, a user creates an Account on the webapp and after that executes > different actions. > That’s relevant if using the queryResultsCache service (or the new planned > “@Action” annotation extension) because the results previously created (i.e., > the Account) might be available on the cache. > So perhaps some mechanism like the nextTransation() method might be also > introduced on FixtureScripts. > What do you think? > ~~~ > Dan's reply: > Makes sense. > There is a nextTransaction() method in the AbstractIntegTest class, you could > see how that is implemented and see if it can be adapted? > Or, another idea is that the framework could run each FixtureScript > automatically in a separate transaction; that would be a better simulation of > a sequence of user interactions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1319) Input dialog for action label for mandatory parameter not shown when the parameter is an view model
[
https://issues.apache.org/jira/browse/ISIS-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Nisevic updated ISIS-1319:
---
Attachment: screenshot-2.png
> Input dialog for action label for mandatory parameter not shown when the
> parameter is an view model
> ---
>
> Key: ISIS-1319
> URL: https://issues.apache.org/jira/browse/ISIS-1319
> Project: Isis
> Issue Type: Bug
> Components: Core: Viewer: Wicket
>Reporter: Vladimir Nisevic
>Assignee: Dan Haywood
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> We have an action method with two mandatory parameters, the first one is a
> viewmodel with autoCompleteXXX and second one an Enum.
> Problem: the sign for mandatory parameter on label (*-suffix) is shown only
> on second label - see attached screenshot
> {code}
> public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "DSL Port") DslPort dslPort,
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "Technology") DslTechnology desiredTechnology)
> throws PlanningException {
> {code}
> Dialog behavior is OK.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-1319) Input dialog for action label for mandatory parameter not shown when the parameter is an view model
[
https://issues.apache.org/jira/browse/ISIS-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Nisevic updated ISIS-1319:
---
Description:
We have an action method with two mandatory parameters, the first one is a
viewmodel with autoCompleteXXX and second one an Enum.
Problem: the sign for mandatory parameter on label (*-suffix) is shown only on
second label - see attached screenshot
{code}
public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "DSL Port") DslPort dslPort,
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "Technology") DslTechnology desiredTechnology) throws
PlanningException {
{code}
Dialog behavior is OK.
was:
We have an action method with two mandatory parameters, the first one is a
viewmodel with autoCompleteXXX and second one an Enum.
Problem: the sign for mandatory parameter on label (*-suffix) is shown only on
second label - see attached screenshot
{code}
public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "DSL Port") DslPort dslPort,
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "Technology") DslTechnology desiredTechnology) throws
PlanningException {
{code}
> Input dialog for action label for mandatory parameter not shown when the
> parameter is an view model
> ---
>
> Key: ISIS-1319
> URL: https://issues.apache.org/jira/browse/ISIS-1319
> Project: Isis
> Issue Type: Bug
> Components: Core: Viewer: Wicket
>Reporter: Vladimir Nisevic
>Assignee: Dan Haywood
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> We have an action method with two mandatory parameters, the first one is a
> viewmodel with autoCompleteXXX and second one an Enum.
> Problem: the sign for mandatory parameter on label (*-suffix) is shown only
> on second label - see attached screenshot
> {code}
> public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "DSL Port") DslPort dslPort,
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "Technology") DslTechnology desiredTechnology)
> throws PlanningException {
> {code}
> Dialog behavior is OK.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-1319) Input dialog for action label for mandatory parameter not shown when the parameter is an view model
[
https://issues.apache.org/jira/browse/ISIS-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Nisevic updated ISIS-1319:
---
Description:
We have an action method with two mandatory parameters, the first one is a
viewmodel with autoCompleteXXX and second one an Enum.
Problem: the sign for mandatory parameter on label (*-suffix) is shown only on
second label - see attached screenshot
{code}
public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "DSL Port") DslPort dslPort,
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "Technology") DslTechnology desiredTechnology) throws
PlanningException {
{code}
was:
We have an action method with two mandatory parameters, the first one is a
viewmodel with autoCompleteXXX and second one an Enum.
Problem: the sign for mandatory parameter on label (*-suffix) is shown only on
second label - see screenshot
{code}
public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "DSL Port") DslPort dslPort,
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "Technology") DslTechnology desiredTechnology) throws
PlanningException {
{code}
> Input dialog for action label for mandatory parameter not shown when the
> parameter is an view model
> ---
>
> Key: ISIS-1319
> URL: https://issues.apache.org/jira/browse/ISIS-1319
> Project: Isis
> Issue Type: Bug
> Components: Core: Viewer: Wicket
>Reporter: Vladimir Nisevic
>Assignee: Dan Haywood
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> We have an action method with two mandatory parameters, the first one is a
> viewmodel with autoCompleteXXX and second one an Enum.
> Problem: the sign for mandatory parameter on label (*-suffix) is shown only
> on second label - see attached screenshot
> {code}
> public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "DSL Port") DslPort dslPort,
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "Technology") DslTechnology desiredTechnology)
> throws PlanningException {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-1319) Input dialog for action label for mandatory parameter not shown when the parameter is an view model
[
https://issues.apache.org/jira/browse/ISIS-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Nisevic updated ISIS-1319:
---
Summary: Input dialog for action label for mandatory parameter not shown
when the parameter is an view model (was: Input dialog for action - *-sign for
mandatory parameter is not shown when parameter is an enitity)
> Input dialog for action label for mandatory parameter not shown when the
> parameter is an view model
> ---
>
> Key: ISIS-1319
> URL: https://issues.apache.org/jira/browse/ISIS-1319
> Project: Isis
> Issue Type: Bug
> Components: Core: Viewer: Wicket
>Reporter: Vladimir Nisevic
>Assignee: Dan Haywood
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> We have an action method with two mandatory parameters, the first one is a
> viewmodel with autoCompleteXXX and second one an Enum.
> Problem: the sign for mandatory parameter on label (*-suffix) is shown only
> on second label - see screenshot
> {code}
> public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "DSL Port") DslPort dslPort,
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "Technology") DslTechnology desiredTechnology)
> throws PlanningException {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-1319) Input dialog for action label for mandatory parameter not shown when the parameter is an view model
[
https://issues.apache.org/jira/browse/ISIS-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Nisevic updated ISIS-1319:
---
Attachment: screenshot-1.png
> Input dialog for action label for mandatory parameter not shown when the
> parameter is an view model
> ---
>
> Key: ISIS-1319
> URL: https://issues.apache.org/jira/browse/ISIS-1319
> Project: Isis
> Issue Type: Bug
> Components: Core: Viewer: Wicket
>Reporter: Vladimir Nisevic
>Assignee: Dan Haywood
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> We have an action method with two mandatory parameters, the first one is a
> viewmodel with autoCompleteXXX and second one an Enum.
> Problem: the sign for mandatory parameter on label (*-suffix) is shown only
> on second label - see screenshot
> {code}
> public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "DSL Port") DslPort dslPort,
> @Parameter(optionality = Optionality.MANDATORY)
> @ParameterLayout(named = "Technology") DslTechnology desiredTechnology)
> throws PlanningException {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ISIS-1319) Input dialog for action - *-sign for mandatory parameter is not shown when parameter is an enitity
Vladimir Nisevic created ISIS-1319:
--
Summary: Input dialog for action - *-sign for mandatory parameter
is not shown when parameter is an enitity
Key: ISIS-1319
URL: https://issues.apache.org/jira/browse/ISIS-1319
Project: Isis
Issue Type: Bug
Components: Core: Viewer: Wicket
Reporter: Vladimir Nisevic
Assignee: Dan Haywood
Priority: Minor
We have an action method with two mandatory parameters, the first one is a
viewmodel with autoCompleteXXX and second one an Enum.
Problem: the sign for mandatory parameter on label (*-suffix) is shown only on
second label - see screenshot
{code}
public DslPortCompatibilityCheckResult dslPortCompatibilityCheck(
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "DSL Port") DslPort dslPort,
@Parameter(optionality = Optionality.MANDATORY)
@ParameterLayout(named = "Technology") DslTechnology desiredTechnology) throws
PlanningException {
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
