I would love to see IModel defined as IModel<T>, personally. But I don't know how that would shake out for < 1.5 people.
On 7/25/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > with 1.5 we could do compile time checking in the constructor of listview: > > something like: > public ListView(final String id, final IModel<List> model) > > Then that type safety is there. We only need then a maybe replacement > for List. > > johan > > Igor Vaynberg wrote: > >>> 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 > > > > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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_idt77&alloc_id492&op=click _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
