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

Dan Haywood updated ISIS-785:
-----------------------------
    Fix Version/s:     (was: viewer-wicket-1.7.0)
                   viewer-wicket-1.8.0

> Implement @BulkParam annotation for executing the same action over a 
> Collection of entities
> -------------------------------------------------------------------------------------------
>
>                 Key: ISIS-785
>                 URL: https://issues.apache.org/jira/browse/ISIS-785
>             Project: Isis
>          Issue Type: Improvement
>          Components: Core, Viewer: Wicket
>            Reporter: Oscar Bou
>            Assignee: Dan Haywood
>             Fix For: viewer-wicket-1.8.0
>
>
> (I've cloned this from ISIS-764, which has now been "repurposed" to some 
> prereq work that will help in implementing this story).
> As an Isis user
> I want to pass as an action parameter a collection of entities 
> In order to avoid repetitive work to the end-user
> The idea is to being able to annotate one of the action params with a new 
> annotation, named @BulkParam, such as in:
> public class TodoItem {
>   ...
>   private TodoItem parentTodoItem;
>   ....
>   public void addRelatedTodo(@Named("To-Do Item") @BulkParam TodoItem 
> todoItem, @Named("Comments") String comments) {
>        ....
>   }
>   ...
> }
> Where the viewer founds it, instead of asking for one TodoItem, it will allow 
> the user to select multiple items.
> Once done, it will execute the action multiple times, passing each time one 
> of the TodoItem selected.
> If there are other params, the viewer will pass on each action invokation the 
> same value for all them.
> Only one param can be annotated with @BulkParam, for avoiding combinatorial 
> explosion (10 items selected of one param, 10 items on the other param would 
> require to be execute 100 times, one for each combination).
> The User Interface could be adapted to the choices or autocomplete parameter 
> facets, for easing the work of the user.
> If "choices", there can be alternative displays (see 
> https://plugins.jquery.com/tag/multiselect/):
> 1. the viewer can present the user a grid or checkbox (like the one in 
> http://liveline.github.io/jquery-checkallbox/) with all choices, and the user 
> can check any of them. Alternative: 
> http://www.ryancramer.com/journal/entries/select_multiple/
> 2. multi-select drop-down, like this ones: 
> http://ivaynberg.github.io/select2/, http://harvesthq.github.io/chosen/, 
> https://github.com/ehynds/jquery-ui-multiselect-widget, 
> http://www.droplist.vinmein.com/. They require minimal changes on the current 
> actions dialog, but does not allow to always view all choices selected (I 
> could live with it).
> If "autocomplete":
> 1. It could be based on a two panels disposition, left and right, where the 
> user incrementally searches on an edit box placed over the left panel, 
> similar to current autocomplete implementation, but placing on the left panel 
> : http://quasipartikel.at/multiselect_next/
> 2. Similar approach to the "choices" one, also with this same widget that 
> admits remote dataset loading and min number of chars entered: 
> http://ivaynberg.github.io/select2/
> As seen, a widget like http://ivaynberg.github.io/select2/ would allow to 
> solve both situations without requiring much changes on the viewer’s action 
> dialog. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to