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

Dan Haywood reopened 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.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 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