Hi Oscar, I really like this idea, in particular (a) the benefit that it only impacts the viewer and (b) the symmetry with our existing @Bulk annotation.
Why don't you raise a ticket for this, capturing the above sketch? Cheers Dan On 4 April 2014 10:54, GESCONSULTOR - Óscar Bou <[email protected]>wrote: > > Hi to all. > > We are evaluating to support on our custom viewer an alternative > implementation to admitting Collections as params. > > I want to detail it here to listen to your suggestions and drawbacks > detected. > > Imagine I want to create a hierarchy of To-Do Items, when one To-Do Item > can only have 1 parent. > > Imagine also that I have the following action: > > public class TodoItem { > > ... > private TodoItem parentTodoItem; > > .... > > @Bulk > public void addChildTodo(@Named("To-Do Item") TodoItem todoItem) { > .... > } > ... > > } > > > If I mark that action as a @Bulk action, I can select on the wicket viewer > multiple TodoItems and add to all them one given To-Do Item as its child. > > Clearly that's not valid, as each To-Do Item can only have one parent. So > it's not possible for all the selected To-Dos to be the parent of the one > passed as a parameter. > > > So I would like to implement something like this: > > public class TodoItem { > > ... > private TodoItem parentTodoItem; > > .... > > public void addChildTodo(@Named("To-Do Items") Collection<TodoItem> > todoItems) { > .... > } > ... > > } > > Where the user inputs a selection of To-Do Items to include all them as > child items for the selected one. As we saw before, this action cannot be > @Bulk as multiple parents are not allowed. > > But currently Isis does not support Collections as parameters. > We can go that way in our custom viewer, but perjaps there's an > alternative approach that, with some limitations, allow us to not break > Isis on Integration Tests, the viewer, etc. (we could also being able to > mark this method as @Programmatic, but we want the params to be validated > for not nulls, etc. by calling them inside a > this.wrap(domainObject).addChildTodo(...); > > The point is that if we introduce a new annotation, @BulkParam, and use it > this way: > > public class TodoItem { > > ... > private TodoItem parentTodoItem; > > .... > > > public void addChildTodo(@Named("To-Do Item") @BulkParam TodoItem > todoItem) { > .... > } > ... > > } > > > The viewer can allow us to choose a Collection of To-Do Items and to > execute for each one, the given action passing it as the parameter. > For that, it must admit a User Interface that allows, for example, to > check a given ToDoItem on a grid, if no auto-complete method is defined for > that entity, or if the entity has an autocomplete, to filter or check on a > grid on a left panel and see the selected items on a right panel. > > The User Interface is really similar to the one needed for implementing > Collections as parameters, so it can be a first step that only affects the > viewer. > > In this context marking it as a @Bulk action does not have any meaning, as > said before, but there are multiple use cases (such as m-n relationships) > where it could also be marked with @Bulk without breaking anything. > > > And it introduce also one implementation advantage over only admitting > Collections. > Imagine for example this other use case: > > > public class TodoItem { > > ... > private TodoItem parentTodoItem; > > .... > > @Bulk > public void addRelatedTodo(@Named("To-Do Item") @BulkParam TodoItem > todoItem) { > .... > } > ... > > } > > > Where on To-Do item can be related with any other given (zero or more). > > On the previous case, only one method implementation would be needed to > support both the case of only one To-Do Item selected, or a Collection of > To-Do Items selected. > > But if the @BulkParam annotation would not be supported, we might decide > to "refactor" the current action: > > public class TodoItem { > > ... > private TodoItem parentTodoItem; > > .... > > @Bulk > public void addRelatedTodo(@Named("To-Do Item") TodoItem todoItem) { > .... > } > ... > > } > > to > > public class TodoItem { > > ... > private TodoItem parentTodoItem; > > .... > > @Bulk > public void addRelatedTodo(@Named("To-Do Items") Collection<TodoItem> > todoItems) { > .... > } > ... > > } > > > And introduce a for-loop on all implementations. > > Or, as an alternative, to implement both actions like this: > > > public class TodoItem { > > ... > private TodoItem parentTodoItem; > > .... > > @Bulk > public void addRelatedTodo(@Named("To-Do Item") TodoItem todoItem) { > .... > } > > @Bulk > public void addMultipleRelatedTodos(@Named("To-Do Items") > Collection<TodoItem> todoItems) { > for (ToDoItem current: todoItems) { > this.wrap(this).addRelatedTodo(current); > } > } > ... > > } > > Being always the addMultipleXXX a dummy implementation. > > > Finishing, perhaps there are unthought drawbacks, but if not, perhaps it > could be considered also as a useful Isis annotation. > > Not sure if it's clear enough ... :-)) > > Any comments ? > > > Thanks! > > Oscar > > > > > > > > > > > > > > > >
