> >Once again, I don't understand the flexibility issue. We were not > >talking about replacing the imodel interface, but the list > interface, > >both approaches can be wrapped in an imodel. What > flexibility do you lose? > > > > > > Actually, I was. Having such a nested specific interface > nested would maybe solve one problem - the problem that in > some cases List isn't the ideal interface for ListView - but > I see more issues here. As one user said last week, it wasn't > immediately clear to him that ListView's models need to > return List instances. He found out not until runtime testing > it. This is where I could see space for improvement: by > having a special purpose model (e.g. like I proposed, but > combined with your suggestion it wouldn't force/ return a > list but another interface, or it would just /be/ that > interface) we would enhance type safety. We could prevent > users from using models that return wrong kinds of objects. > We can't prevent that now until runtime. On top of that, > there was the discussion about whether ListView and the List > interface were good matches.
I also do not think forcing a specific model interface onto a component at such a high level is a good idea. You cannot do all the type checking at compile time, at some point the programmer needs to know what they are doing. What I was trying to achieve is a better low level interface that makes it much easier to provide your own implementation if the default one doesn't work for you. Igor ------------------------------------------------------- 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
