Sure!
There's a small extension to it, for admitting multiple params on the action signature, that was also needed by us.
If, instead of having:
public class TodoItem {
...
private TodoItem parentTodoItem;
....
@Bulk
public void addRelatedTodo(@Named("To-Do Item") @BulkParam TodoItem
todoItem) {
....
}
...
}
I have:
public class TodoItem {
...
private TodoItem parentTodoItem;
....
@Bulk
public void addRelatedTodo(@Named("To-Do Item") @BulkParam TodoItem
todoItem, @Named("Comments") String comments) {
....
}
...
}
The viewer would pass the same description on every action call.
So, only one param can be annotated with @BulkParam, but the viewer will ask for the other params (the usual way) and pass the same values on each action call.
I'll raise a ticket.
Thanks,
Oscar
El 05/04/2014, a las 11:19, Dan Haywood < [email protected]> escribió: 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
Óscar Bou Bou Responsable de Producto Auditor Jefe de Certificación ISO 27001 en BSI CISA, CRISC, APMG ISO 20000, ITIL-F
 902 900 231 / 620 267 520
 http://www.twitter.com/oscarbou
 http://es.linkedin.com/in/oscarbou
 http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
|
