[
https://issues.apache.org/jira/browse/ISIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360634#comment-16360634
]
ASF subversion and git services commented on ISIS-1585:
-------------------------------------------------------
Commit f8a5a2eea74a72eda0b2a4911e25f01b19d9c80b in isis's branch
refs/heads/maint-1.16.1 from [~danhaywood]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f8a5a2e ]
ISIS-1585: extends to support derivation of choices for both scalar and
collection parameters.
Also:
- extends @Action with associateWithSequence
- deprecates bulk actions (documentation and API)
- moves PostProcessor impl to new package
- fixes rebuildMetaModel to call the PostProcessor
- updates docs.
> 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)
