Dan Haywood updated ISIS-1585:
    Summary: 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.  (was: 
Allow objects in parented collections to be selected, automatically passed as 
defaults for collection parameter of associated actions.)

> 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:
>            Reporter: Dan Haywood
>            Assignee: Dan Haywood
>            Priority: Minor
>             Fix For: 1.16.1
> 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

Reply via email to