ASF subversion and git services commented on ISIS-1585:

Commit 655dd28110f9e7dfbbc86767d8c97bea5f31660e in isis's branch 
refs/heads/maint-1.16.1 from [~danhaywood]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=655dd28 ]

ISIS-1585: fixes for mixins, and not honouring associateWith

The logic to set up choices for action parameters was not (!) in fact filtering 
on the associated with collections, resulting in ChoicesFacet being installed 
where it shouldna been.
And, for choices installed on a mixin action, need to disambiguate the target.

- metamodel validation error resulting in non-@Programmatic public methods in 
SpecificationLoader (now made @Programmatic).

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

Reply via email to