[ 
https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Haywood updated ISIS-1585:
------------------------------
    Description: 
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<ToDoItem> getNotYetCompleted() { ... }    // our parented 
collection

    @MemberOrder(named="notYetCompleted", sequence="1")
    public ToDoAppDashboard markAsCompleted(
                                                    List<ToDoItem> 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<ToDoItem> 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:java}
    public List<ToDoItem> default0MarkAsCompleted() { return 
selectedItemService.selectedFor(this, "notYetCompleted"); }
{code}
As I say, these choices and defaults methods wouldn't actually be written by 
the developer, I'm just writing them here to explain what the framework would 
do automatically.

Other thoughts:
 * if the action takes only a single list of parameters, then there should be 
no prompt, simply invoke the action.

 * as a refinement, rather than (in the action prompt) render the actual list 
of selected items in a multi-select field, the Wicket viewer could instead just 
render an unmodifiable label, eg: "5 items selected". This would be a matter of 
having a new ComponentFactory for the parameter/property that takes precedence 
over multi-select for those cases when the parameter has been defaulted from 
the selection.

 * we might need an additional annotation/attribute to handle the edge case of 
an action that takes two or more lists of parameters of the same type (in which 
case there would be ambiguity as to which it should contribute to).. But as a 
simplification, in such a case probably ok to automatically default just the 
first such list.

[1] [https://github.com/isisaddons/isis-app-todoapp]
 [2] [http://imgur.com/a/YnhQT]
 [3] 
[https://github.com/isisaddons/isis-app-todoapp/blob/master/dom/src/main/java/todoapp/dom/todoitem/ToDoItem.java#L331]
 [4] [http://isis.apache.org/guides/rgant.html#_rgant-Action_invokeOn]
 [5] 
[https://github.com/apache/isis/tree/master/core/metamodel/src/main/java/org/apache/isis/core/metamodel/services]
 [6] 
[https://github.com/apache/isis/tree/master/core/runtime/src/main/java/org/apache/isis/core/runtime/services]
 
 [7] 
[https://github.com/apache/isis/tree/master/core/applib/src/main/java/org/apache/isis/applib/services]
 [8] [http://isis.apache.org/guides/rgfis.html]

  was:
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<ToDoItem> getNotYetCompleted() { ... }    // our parented 
collection

    @MemberOrder(named="notYetCompleted", sequence="1")
    public ToDoAppDashboard markAsCompleted(
                                                    List<ToDoItem> 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<ToDoItem> 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<ToDoItem> default0MarkAsCompleted() { return 
selectedItemService.selectedFor(this, "notYetCompleted"); }
{code}

As I say, these choices and defaults methods wouldn't actually be written by 
the developer, I'm just writing them here to explain what the framework would 
do automatically.

Other thoughts:

* if the action takes only a single list of parameters, then there should be no 
prompt, simply invoke the action.

* as a refinement, rather than (in the action prompt) render the actual list of 
selected items in a multi-select field, the Wicket viewer could instead just 
render an unmodifiable label, eg: "5 items selected".  This would be a matter 
of having a new ComponentFactory for the parameter/property that takes 
precedence over multi-select for those cases when the parameter has been 
defaulted from the selection.

* we might need an additional annotation/attribute to handle the edge case of 
an action that takes two or more lists of parameters of the same type (in which 
case there would be ambiguity as to which it should contribute to)..  But as a 
simplification, in such a case probably ok to automatically default just the 
first such list.



[1] https://github.com/isisaddons/isis-app-todoapp
[2] http://imgur.com/a/YnhQT
[3] 
https://github.com/isisaddons/isis-app-todoapp/blob/master/dom/src/main/java/todoapp/dom/todoitem/ToDoItem.java#L331
[4] http://isis.apache.org/guides/rgant.html#_rgant-Action_invokeOn
[5] 
https://github.com/apache/isis/tree/master/core/metamodel/src/main/java/org/apache/isis/core/metamodel/services
[6] 
https://github.com/apache/isis/tree/master/core/runtime/src/main/java/org/apache/isis/core/runtime/services
 
[7] 
https://github.com/apache/isis/tree/master/core/applib/src/main/java/org/apache/isis/applib/services
[8] http://isis.apache.org/guides/rgfis.html


> 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<ToDoItem> getNotYetCompleted() { ... }    // our parented 
> collection
>     @MemberOrder(named="notYetCompleted", sequence="1")
>     public ToDoAppDashboard markAsCompleted(
>                                                     List<ToDoItem> 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<ToDoItem> 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:java}
>     public List<ToDoItem> default0MarkAsCompleted() { return 
> selectedItemService.selectedFor(this, "notYetCompleted"); }
> {code}
> As I say, these choices and defaults methods wouldn't actually be written by 
> the developer, I'm just writing them here to explain what the framework would 
> do automatically.
> Other thoughts:
>  * if the action takes only a single list of parameters, then there should be 
> no prompt, simply invoke the action.
>  * as a refinement, rather than (in the action prompt) render the actual list 
> of selected items in a multi-select field, the Wicket viewer could instead 
> just render an unmodifiable label, eg: "5 items selected". This would be a 
> matter of having a new ComponentFactory for the parameter/property that takes 
> precedence over multi-select for those cases when the parameter has been 
> defaulted from the selection.
>  * we might need an additional annotation/attribute to handle the edge case 
> of an action that takes two or more lists of parameters of the same type (in 
> which case there would be ambiguity as to which it should contribute to).. 
> But as a simplification, in such a case probably ok to automatically default 
> just the first such list.
> [1] [https://github.com/isisaddons/isis-app-todoapp]
>  [2] [http://imgur.com/a/YnhQT]
>  [3] 
> [https://github.com/isisaddons/isis-app-todoapp/blob/master/dom/src/main/java/todoapp/dom/todoitem/ToDoItem.java#L331]
>  [4] [http://isis.apache.org/guides/rgant.html#_rgant-Action_invokeOn]
>  [5] 
> [https://github.com/apache/isis/tree/master/core/metamodel/src/main/java/org/apache/isis/core/metamodel/services]
>  [6] 
> [https://github.com/apache/isis/tree/master/core/runtime/src/main/java/org/apache/isis/core/runtime/services]
>  
>  [7] 
> [https://github.com/apache/isis/tree/master/core/applib/src/main/java/org/apache/isis/applib/services]
>  [8] [http://isis.apache.org/guides/rgfis.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to