On Wed, 2009-03-04 at 08:27 -0800, Scott Swank wrote: > Does AbstractReadOnlyModel accomplish what you're talking about?
Not really. I suggest a separate interface that does not extend IModel. Instead IModel should extend that one (since it adds the setter)... And of course that interface should be used within the declarations to show that only read access is used... Regards, Johannes > > Scott > > 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
