On Wed, 2009-03-04 at 09:14 -0800, Igor Vaynberg wrote: > components that deal with collections in wicket always reuse the same > instance of collection is one was provided where it makes sense.
Yes, and therefore a setter is not necessary. > setobject is still called on the model, but is called with the same > instance of collection. this is necessary so that if you have a model > that translates a collection of one type to a collection of another > can perform the conversion when the component pushes new data into it. And this is just a *misuse* of the given method... Why not create a own model interface for collections and add some sort of conversion method/object? Regards, Johannes > > -igor > > On Wed, Mar 4, 2009 at 4:50 AM, Johannes Schneider > <maili...@cedarsoft.com> wrote: > > 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
