I think our previous discussion was a bit misunderstood. I was not trying to
replace the imodel interface for the exact reason you mentioned below, what
I was trying to replace is the model object interface which is currently a
list. So instead of casting the model object to a list and retrieving data,
the listview would cast it to this more defined/specific interface and use
that to retrieve data, convert objects to ids/models, etc. This same
approach can be used for choice lists/etc.
Igor
--- Previous Message ---
We're thinking about how specific models (like for ListView) would look
like. Would could have an interface like:
public interface IListModel extends IDetachable
{
List getList(Component component);
void setList(final Component component, List list);
}
And force using that in ListViews.
And advantage of this - like someone pointed out earlier this week - is that
it is clear what kind of objects it has to provide, and that we force that
statically.
HOWEVER (yes a big however), this would also mean a serious loss of
flexibility.
Right now, you can use any model you want, including e.g. property models.
Not anymore in our new situation. Sure, we could build models that support
that, but it would mean that the number of models seriously increases,
making it harder for people to dig through the options.
Any thoughts about this?
Eelco
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
