Dan Haywood created ISIS-1585:
---------------------------------
Summary: 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: 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<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
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
