[jira] [Assigned] (ISIS-1585) Allow objects in parented collections to be selected, automatically passed as defaults for collection parameter of associated actions.
[ https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood reassigned ISIS-1585: - Assignee: Dan Haywood > Allow objects in parented collections to be selected, automatically passed as > defaults for collection parameter of associated actions. > -- > > Key: ISIS-1585 > URL: https://issues.apache.org/jira/browse/ISIS-1585 > Project: Isis > Issue Type: New Feature > Components: Core >Affects Versions: 1.13.2.1 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: 1.16.1 > > > As per Dan's email to Stef: > > Currently we have the concept of a "bulk" action; this is one that operates > only on a standalone collection of objects (ie as returned by an action > invocation). When one or bulk actions are defined, then the viewer renders > the bulk actions' buttons above the collection. > There's an example in the todoapp [1]. Run the app with the > ToDoAppAppManifestWithFixtures, then run ToDos > Not Yet Complete. You'll > see [2], with "Not Yet Completed" as one of the actions. This is because of > the code in [3], by way of @Action(invokeOn=OBJECT_AND_COLLECTION) [4] > There are however some restrictions to this: > * bulk actions cannot take parameters > * it isn't possible to invoke actions on parented collections, only on > standalone collections. > In 1.14.0-SNAPSHOT I recently added support for actions that accept > collections as parameters. This hasn't yet been released, but will be the > "headline" feature in 1.14.0. Building on that I see an opportunity to build > upon it to (a) lift both restrictions and (b) remove some code from the > framework. > So, my idea is: > * add the ability to have selections on parented collections too > * for actions that are "associated" with a parented collection and that have > a collection parameter taking the type of that list, have the framework > automatically use the selected objects as the argument values. > * we deprecate the whole concept of bulk actions (ie @Action#invokeOn=...) to > remove in the future. Instead, the replacement would simply be a parented > collection of a view model. > We currently associate actions with collections using @MemberOrder(...); or > this can be done using the .layout.xml file. So the coding model would be > something like: > {code} > public class ToDoAppDashboard { // our existing view model for the home page > public List getNotYetCompleted() { ... }// our parented > collection > @MemberOrder(named="notYetCompleted", sequence="1") > public ToDoAppDashboard markAsCompleted( > List items, > boolean > automaticallyDelete) { // an additional parameter, just to demonstrate > the point > ... > } > } > {code} > and ideally this is all that would be needed. The user would select items > using checkboxes on the "notYetCompleted" collection, and the would be able > to invoke the "markAsCompleted" action with the first parameter already > populated/defaulted. > Under the covers, the selected items would correspond to a DefaultedFacet for > the parameter, and there would be a DisabledFacet on the entire action if no > objects has been selected. > I can see several steps to implement this. As well as the actual UI changes > to the Wicket viewer (CollectionAsContentsTable or something like that), > there will also be some metamodel stuff to add in, ie new FacetFactories. > The support we currently have for lists of objects as parameters requires > that there's a ChoicesFacet for the parameter type. So initially the > framework would need to generate this facet behind the scenes; it's > implementation would be equivalent to: > {code} > public List choices0MarkAsCompleted() { return > getNotYetCompleted(); } > {code} > For the actual selected items, I am thinking it would be useful to introduce > an internal domain service for use by the framework, called something like > SelectedItemService. You'll see that the framework has a whole bunch defined > in the metamodel module [5], and a bunch more in the runtime module [6]. > (Many of these are also exposed as formal API in the applib [7], but not all; > see also [8]). > Anyway, so SelectedItemService (annotated with @RequestScoped, "obviously") > could be a way to provide the list of items currently selected. The > generated DefaultedFacet would be equivalent to: > {code} > public List default0MarkAsCompleted() { return > selectedItemService.selectedFor(this, "notYetCompleted"); } > {code} > As I say, these choices and de
[jira] [Assigned] (ISIS-1585) Allow objects in parented collections to be selected, automatically passed as defaults for collection parameter of associated actions.
[ https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood reassigned ISIS-1585: - Assignee: (was: Dan Haywood) > Allow objects in parented collections to be selected, automatically passed as > defaults for collection parameter of associated actions. > -- > > Key: ISIS-1585 > URL: https://issues.apache.org/jira/browse/ISIS-1585 > Project: Isis > Issue Type: New Feature > Components: Core >Affects Versions: 1.13.2.1 >Reporter: Dan Haywood >Priority: Minor > Fix For: 2.3.0 > > > As per Dan's email to Stef: > > Currently we have the concept of a "bulk" action; this is one that operates > only on a standalone collection of objects (ie as returned by an action > invocation). When one or bulk actions are defined, then the viewer renders > the bulk actions' buttons above the collection. > There's an example in the todoapp [1]. Run the app with the > ToDoAppAppManifestWithFixtures, then run ToDos > Not Yet Complete. You'll > see [2], with "Not Yet Completed" as one of the actions. This is because of > the code in [3], by way of @Action(invokeOn=OBJECT_AND_COLLECTION) [4] > There are however some restrictions to this: > * bulk actions cannot take parameters > * it isn't possible to invoke actions on parented collections, only on > standalone collections. > In 1.14.0-SNAPSHOT I recently added support for actions that accept > collections as parameters. This hasn't yet been released, but will be the > "headline" feature in 1.14.0. Building on that I see an opportunity to build > upon it to (a) lift both restrictions and (b) remove some code from the > framework. > So, my idea is: > * add the ability to have selections on parented collections too > * for actions that are "associated" with a parented collection and that have > a collection parameter taking the type of that list, have the framework > automatically use the selected objects as the argument values. > * we deprecate the whole concept of bulk actions (ie @Action#invokeOn=...) to > remove in the future. Instead, the replacement would simply be a parented > collection of a view model. > We currently associate actions with collections using @MemberOrder(...); or > this can be done using the .layout.xml file. So the coding model would be > something like: > {code} > public class ToDoAppDashboard { // our existing view model for the home page > public List getNotYetCompleted() { ... }// our parented > collection > @MemberOrder(named="notYetCompleted", sequence="1") > public ToDoAppDashboard markAsCompleted( > List items, > boolean > automaticallyDelete) { // an additional parameter, just to demonstrate > the point > ... > } > } > {code} > and ideally this is all that would be needed. The user would select items > using checkboxes on the "notYetCompleted" collection, and the would be able > to invoke the "markAsCompleted" action with the first parameter already > populated/defaulted. > Under the covers, the selected items would correspond to a DefaultedFacet for > the parameter, and there would be a DisabledFacet on the entire action if no > objects has been selected. > I can see several steps to implement this. As well as the actual UI changes > to the Wicket viewer (CollectionAsContentsTable or something like that), > there will also be some metamodel stuff to add in, ie new FacetFactories. > The support we currently have for lists of objects as parameters requires > that there's a ChoicesFacet for the parameter type. So initially the > framework would need to generate this facet behind the scenes; it's > implementation would be equivalent to: > {code} > public List choices0MarkAsCompleted() { return > getNotYetCompleted(); } > {code} > For the actual selected items, I am thinking it would be useful to introduce > an internal domain service for use by the framework, called something like > SelectedItemService. You'll see that the framework has a whole bunch defined > in the metamodel module [5], and a bunch more in the runtime module [6]. > (Many of these are also exposed as formal API in the applib [7], but not all; > see also [8]). > Anyway, so SelectedItemService (annotated with @RequestScoped, "obviously") > could be a way to provide the list of items currently selected. The > generated DefaultedFacet would be equivalent to: > {code} > public List default0MarkAsCompleted() { return > selectedItemService.selectedFor(this, "notYetCompleted"); } > {code} > As I say, these choices and defaults methods wouldn't a
[jira] [Assigned] (ISIS-1585) Allow objects in parented collections to be selected, automatically passed as defaults for collection parameter of associated actions.
[ https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood reassigned ISIS-1585: - Assignee: Dan Haywood (was: Stefano Cascarini) > Allow objects in parented collections to be selected, automatically passed as > defaults for collection parameter of associated actions. > -- > > Key: ISIS-1585 > URL: https://issues.apache.org/jira/browse/ISIS-1585 > Project: Isis > Issue Type: New Feature > Components: Core >Affects Versions: 1.13.2.1 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: 1.16.0 > > > As per Dan's email to Stef: > > Currently we have the concept of a "bulk" action; this is one that operates > only on a standalone collection of objects (ie as returned by an action > invocation). When one or bulk actions are defined, then the viewer renders > the bulk actions' buttons above the collection. > There's an example in the todoapp [1]. Run the app with the > ToDoAppAppManifestWithFixtures, then run ToDos > Not Yet Complete. You'll > see [2], with "Not Yet Completed" as one of the actions. This is because of > the code in [3], by way of @Action(invokeOn=OBJECT_AND_COLLECTION) [4] > There are however some restrictions to this: > * bulk actions cannot take parameters > * it isn't possible to invoke actions on parented collections, only on > standalone collections. > In 1.14.0-SNAPSHOT I recently added support for actions that accept > collections as parameters. This hasn't yet been released, but will be the > "headline" feature in 1.14.0. Building on that I see an opportunity to build > upon it to (a) lift both restrictions and (b) remove some code from the > framework. > So, my idea is: > * add the ability to have selections on parented collections too > * for actions that are "associated" with a parented collection and that have > a collection parameter taking the type of that list, have the framework > automatically use the selected objects as the argument values. > * we deprecate the whole concept of bulk actions (ie @Action#invokeOn=...) to > remove in the future. Instead, the replacement would simply be a parented > collection of a view model. > We currently associate actions with collections using @MemberOrder(...); or > this can be done using the .layout.xml file. So the coding model would be > something like: > {code} > public class ToDoAppDashboard { // our existing view model for the home page > public List getNotYetCompleted() { ... }// our parented > collection > @MemberOrder(named="notYetCompleted", sequence="1") > public ToDoAppDashboard markAsCompleted( > List items, > boolean > automaticallyDelete) { // an additional parameter, just to demonstrate > the point > ... > } > } > {code} > and ideally this is all that would be needed. The user would select items > using checkboxes on the "notYetCompleted" collection, and the would be able > to invoke the "markAsCompleted" action with the first parameter already > populated/defaulted. > Under the covers, the selected items would correspond to a DefaultedFacet for > the parameter, and there would be a DisabledFacet on the entire action if no > objects has been selected. > I can see several steps to implement this. As well as the actual UI changes > to the Wicket viewer (CollectionAsContentsTable or something like that), > there will also be some metamodel stuff to add in, ie new FacetFactories. > The support we currently have for lists of objects as parameters requires > that there's a ChoicesFacet for the parameter type. So initially the > framework would need to generate this facet behind the scenes; it's > implementation would be equivalent to: > {code} > public List choices0MarkAsCompleted() { return > getNotYetCompleted(); } > {code} > For the actual selected items, I am thinking it would be useful to introduce > an internal domain service for use by the framework, called something like > SelectedItemService. You'll see that the framework has a whole bunch defined > in the metamodel module [5], and a bunch more in the runtime module [6]. > (Many of these are also exposed as formal API in the applib [7], but not all; > see also [8]). > Anyway, so SelectedItemService (annotated with @RequestScoped, "obviously") > could be a way to provide the list of items currently selected. The > generated DefaultedFacet would be equivalent to: > {code} > public List default0MarkAsCompleted() { return > selectedItemService.selectedFor(this, "notYetCompleted"); } > {code} > As I
[jira] [Assigned] (ISIS-1585) Allow objects in parented collections to be selected, automatically passed as defaults for collection parameter of associated actions.
[ https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood reassigned ISIS-1585: - Assignee: Stefano Cascarini (was: Dan Haywood) > Allow objects in parented collections to be selected, automatically passed as > defaults for collection parameter of associated actions. > -- > > Key: ISIS-1585 > URL: https://issues.apache.org/jira/browse/ISIS-1585 > Project: Isis > Issue Type: New Feature > Components: Core >Affects Versions: 1.13.2.1 >Reporter: Dan Haywood >Assignee: Stefano Cascarini >Priority: Minor > Fix For: 1.15.0 > > > As per Dan's email to Stef: > > Currently we have the concept of a "bulk" action; this is one that operates > only on a standalone collection of objects (ie as returned by an action > invocation). When one or bulk actions are defined, then the viewer renders > the bulk actions' buttons above the collection. > There's an example in the todoapp [1]. Run the app with the > ToDoAppAppManifestWithFixtures, then run ToDos > Not Yet Complete. You'll > see [2], with "Not Yet Completed" as one of the actions. This is because of > the code in [3], by way of @Action(invokeOn=OBJECT_AND_COLLECTION) [4] > There are however some restrictions to this: > * bulk actions cannot take parameters > * it isn't possible to invoke actions on parented collections, only on > standalone collections. > In 1.14.0-SNAPSHOT I recently added support for actions that accept > collections as parameters. This hasn't yet been released, but will be the > "headline" feature in 1.14.0. Building on that I see an opportunity to build > upon it to (a) lift both restrictions and (b) remove some code from the > framework. > So, my idea is: > * add the ability to have selections on parented collections too > * for actions that are "associated" with a parented collection and that have > a collection parameter taking the type of that list, have the framework > automatically use the selected objects as the argument values. > * we deprecate the whole concept of bulk actions (ie @Action#invokeOn=...) to > remove in the future. Instead, the replacement would simply be a parented > collection of a view model. > We currently associate actions with collections using @MemberOrder(...); or > this can be done using the .layout.xml file. So the coding model would be > something like: > {code} > public class ToDoAppDashboard { // our existing view model for the home page > public List getNotYetCompleted() { ... }// our parented > collection > @MemberOrder(named="notYetCompleted", sequence="1") > public ToDoAppDashboard markAsCompleted( > List items, > boolean > automaticallyDelete) { // an additional parameter, just to demonstrate > the point > ... > } > } > {code} > and ideally this is all that would be needed. The user would select items > using checkboxes on the "notYetCompleted" collection, and the would be able > to invoke the "markAsCompleted" action with the first parameter already > populated/defaulted. > Under the covers, the selected items would correspond to a DefaultedFacet for > the parameter, and there would be a DisabledFacet on the entire action if no > objects has been selected. > I can see several steps to implement this. As well as the actual UI changes > to the Wicket viewer (CollectionAsContentsTable or something like that), > there will also be some metamodel stuff to add in, ie new FacetFactories. > The support we currently have for lists of objects as parameters requires > that there's a ChoicesFacet for the parameter type. So initially the > framework would need to generate this facet behind the scenes; it's > implementation would be equivalent to: > {code} > public List choices0MarkAsCompleted() { return > getNotYetCompleted(); } > {code} > For the actual selected items, I am thinking it would be useful to introduce > an internal domain service for use by the framework, called something like > SelectedItemService. You'll see that the framework has a whole bunch defined > in the metamodel module [5], and a bunch more in the runtime module [6]. > (Many of these are also exposed as formal API in the applib [7], but not all; > see also [8]). > Anyway, so SelectedItemService (annotated with @RequestScoped, "obviously") > could be a way to provide the list of items currently selected. The > generated DefaultedFacet would be equivalent to: > {code} > public List default0MarkAsCompleted() { return > selectedItemService.selectedFor(this, "notYetCompleted"); } > {code}
[jira] [Assigned] (ISIS-1585) Allow objects in parented collections to be selected, automatically passed as defaults for collection parameter of associated actions.
[ https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood reassigned ISIS-1585: - Assignee: Dan Haywood (was: Stefano Cascarini) > Allow objects in parented collections to be selected, automatically passed as > defaults for collection parameter of associated actions. > -- > > Key: ISIS-1585 > URL: https://issues.apache.org/jira/browse/ISIS-1585 > Project: Isis > Issue Type: New Feature > Components: Core >Affects Versions: 1.13.2.1 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: 1.15.0 > > > As per Dan's email to Stef: > > Currently we have the concept of a "bulk" action; this is one that operates > only on a standalone collection of objects (ie as returned by an action > invocation). When one or bulk actions are defined, then the viewer renders > the bulk actions' buttons above the collection. > There's an example in the todoapp [1]. Run the app with the > ToDoAppAppManifestWithFixtures, then run ToDos > Not Yet Complete. You'll > see [2], with "Not Yet Completed" as one of the actions. This is because of > the code in [3], by way of @Action(invokeOn=OBJECT_AND_COLLECTION) [4] > There are however some restrictions to this: > * bulk actions cannot take parameters > * it isn't possible to invoke actions on parented collections, only on > standalone collections. > In 1.14.0-SNAPSHOT I recently added support for actions that accept > collections as parameters. This hasn't yet been released, but will be the > "headline" feature in 1.14.0. Building on that I see an opportunity to build > upon it to (a) lift both restrictions and (b) remove some code from the > framework. > So, my idea is: > * add the ability to have selections on parented collections too > * for actions that are "associated" with a parented collection and that have > a collection parameter taking the type of that list, have the framework > automatically use the selected objects as the argument values. > * we deprecate the whole concept of bulk actions (ie @Action#invokeOn=...) to > remove in the future. Instead, the replacement would simply be a parented > collection of a view model. > We currently associate actions with collections using @MemberOrder(...); or > this can be done using the .layout.xml file. So the coding model would be > something like: > {code} > public class ToDoAppDashboard { // our existing view model for the home page > public List getNotYetCompleted() { ... }// our parented > collection > @MemberOrder(named="notYetCompleted", sequence="1") > public ToDoAppDashboard markAsCompleted( > List items, > boolean > automaticallyDelete) { // an additional parameter, just to demonstrate > the point > ... > } > } > {code} > and ideally this is all that would be needed. The user would select items > using checkboxes on the "notYetCompleted" collection, and the would be able > to invoke the "markAsCompleted" action with the first parameter already > populated/defaulted. > Under the covers, the selected items would correspond to a DefaultedFacet for > the parameter, and there would be a DisabledFacet on the entire action if no > objects has been selected. > I can see several steps to implement this. As well as the actual UI changes > to the Wicket viewer (CollectionAsContentsTable or something like that), > there will also be some metamodel stuff to add in, ie new FacetFactories. > The support we currently have for lists of objects as parameters requires > that there's a ChoicesFacet for the parameter type. So initially the > framework would need to generate this facet behind the scenes; it's > implementation would be equivalent to: > {code} > public List choices0MarkAsCompleted() { return > getNotYetCompleted(); } > {code} > For the actual selected items, I am thinking it would be useful to introduce > an internal domain service for use by the framework, called something like > SelectedItemService. You'll see that the framework has a whole bunch defined > in the metamodel module [5], and a bunch more in the runtime module [6]. > (Many of these are also exposed as formal API in the applib [7], but not all; > see also [8]). > Anyway, so SelectedItemService (annotated with @RequestScoped, "obviously") > could be a way to provide the list of items currently selected. The > generated DefaultedFacet would be equivalent to: > {code} > public List default0MarkAsCompleted() { return > selectedItemService.selectedFor(this, "notYetCompleted"); } > {code} > As I
[jira] [Assigned] (ISIS-1585) Allow objects in parented collections to be selected, automatically passed as defaults for collection parameter of associated actions.
[ https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood reassigned ISIS-1585: - Assignee: Stefano Cascarini > Allow objects in parented collections to be selected, automatically passed as > defaults for collection parameter of associated actions. > -- > > Key: ISIS-1585 > URL: https://issues.apache.org/jira/browse/ISIS-1585 > Project: Isis > Issue Type: New Feature > Components: Core >Affects Versions: 1.13.2.1 >Reporter: Dan Haywood >Assignee: Stefano Cascarini >Priority: Minor > Fix For: 1.15.0 > > > As per Dan's email to Stef: > > Currently we have the concept of a "bulk" action; this is one that operates > only on a standalone collection of objects (ie as returned by an action > invocation). When one or bulk actions are defined, then the viewer renders > the bulk actions' buttons above the collection. > There's an example in the todoapp [1]. Run the app with the > ToDoAppAppManifestWithFixtures, then run ToDos > Not Yet Complete. You'll > see [2], with "Not Yet Completed" as one of the actions. This is because of > the code in [3], by way of @Action(invokeOn=OBJECT_AND_COLLECTION) [4] > There are however some restrictions to this: > * bulk actions cannot take parameters > * it isn't possible to invoke actions on parented collections, only on > standalone collections. > In 1.14.0-SNAPSHOT I recently added support for actions that accept > collections as parameters. This hasn't yet been released, but will be the > "headline" feature in 1.14.0. Building on that I see an opportunity to build > upon it to (a) lift both restrictions and (b) remove some code from the > framework. > So, my idea is: > * add the ability to have selections on parented collections too > * for actions that are "associated" with a parented collection and that have > a collection parameter taking the type of that list, have the framework > automatically use the selected objects as the argument values. > * we deprecate the whole concept of bulk actions (ie @Action#invokeOn=...) to > remove in the future. Instead, the replacement would simply be a parented > collection of a view model. > We currently associate actions with collections using @MemberOrder(...); or > this can be done using the .layout.xml file. So the coding model would be > something like: > {code} > public class ToDoAppDashboard { // our existing view model for the home page > public List getNotYetCompleted() { ... }// our parented > collection > @MemberOrder(named="notYetCompleted", sequence="1") > public ToDoAppDashboard markAsCompleted( > List items, > boolean > automaticallyDelete) { // an additional parameter, just to demonstrate > the point > ... > } > } > {code} > and ideally this is all that would be needed. The user would select items > using checkboxes on the "notYetCompleted" collection, and the would be able > to invoke the "markAsCompleted" action with the first parameter already > populated/defaulted. > Under the covers, the selected items would correspond to a DefaultedFacet for > the parameter, and there would be a DisabledFacet on the entire action if no > objects has been selected. > I can see several steps to implement this. As well as the actual UI changes > to the Wicket viewer (CollectionAsContentsTable or something like that), > there will also be some metamodel stuff to add in, ie new FacetFactories. > The support we currently have for lists of objects as parameters requires > that there's a ChoicesFacet for the parameter type. So initially the > framework would need to generate this facet behind the scenes; it's > implementation would be equivalent to: > {code} > public List choices0MarkAsCompleted() { return > getNotYetCompleted(); } > {code} > For the actual selected items, I am thinking it would be useful to introduce > an internal domain service for use by the framework, called something like > SelectedItemService. You'll see that the framework has a whole bunch defined > in the metamodel module [5], and a bunch more in the runtime module [6]. > (Many of these are also exposed as formal API in the applib [7], but not all; > see also [8]). > Anyway, so SelectedItemService (annotated with @RequestScoped, "obviously") > could be a way to provide the list of items currently selected. The > generated DefaultedFacet would be equivalent to: > {code} > public List default0MarkAsCompleted() { return > selectedItemService.selectedFor(this, "notYetCompleted"); } > {code} > As I say, these ch