[
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)
