Does AbstractReadOnlyModel accomplish what you're talking about?

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

Reply via email to