[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 and collection parameters.

["Dan Haywood (JIRA)" <ji...@apache.org>]

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