[jira] [Resolved] (ISIS-1585) Allow objects in parented collections to be selected, automatically passed as defaults for collection parameter of associated actions. Also infer choices for both scalar
[
https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood resolved ISIS-1585.
---
Resolution: Fixed
> Allow objects in parented collections to be selected, automatically passed as
> defaults for collection parameter of associated actions. Also infer choices
> for both scalar and collection parameters.
> -
>
> 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
>
>
> This in effect deprecates the concept of bulk actions... instead use a view
> model as a wrapper around a collection returned by an action.
>
> 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:java}
> 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:java}
> 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
[jira] [Resolved] (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 resolved ISIS-1585.
---
Resolution: Fixed
> 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 defaults
[jira] [Resolved] (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 resolved ISIS-1585.
---
Resolution: Unresolved
moving to resolved only cos can't move back to "TO DO"
> 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,
