Hi,

the concept of IModel seems to be very obvious. It is simply some kind
of reference and offers a getter and a setter.

When used with ordinary object, everything works fine. An IModel that
contains a String can easily be mapped to a TextField.
The text field calls "getObject" to show the initial value and sets the
changed string to the model using "setObject" on form commit.


Everything becomes a little more complicated when collections are
affected. The problem is, that it is not obvious what those collections
represent.

1) A collection might be read-only (e.g. the possible choices for a
selection).
2) But it also might be necessary to add/remove single elements (e.g.
privileged users shown within a shuffle list).
3) And sometimes the complete collection is changed (can't find an
example here).


IModel only supports the *third* method where the complete collection is
replaced. 
(Don't forget that the reference to the collection changes which will
lead to several other problems.)
I strongly recommend the usage of a wrapping class for that case.
But this case is not very common. Maybe someone finds a good example - I
can't. 


For the other two cases it does *not* make any sense to call
IModel#setObject.


Summary: Nearly in every case when the IModel contains a collection, the
"setObject" method does not make any sense and must not be called.


Conclusion: I think we should have created some sort of IModelProvider
(contains only the getObject method) and IModel (with both methods).
Components that just *read* values from the model, accept the read only
interface now.

For special cases where a magic component adds/removes elements to a
collection, we need some sort of ICollectionModel that offers "add" and
"remove" methods (but no setter).
That interface - of course - will be based upon a collection *without*
wildcards...



Regards,

Johannes Schneider





 







---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to