[
https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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: 1.13.2.1
> 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
(v7.6.3#76005)
