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
