On Thu, Apr 24, 2008 at 3:42 AM, Jan Kriesten <[EMAIL PROTECTED]> wrote: > > Hi, > > I have a usecase where the current proposed generic Interface for > IDataProvider with upcoming v1.4 of Wicket would break the implementation > concept working with Wicket 1.3. The usecase needs different types for > iterator + model. Example and explanation are found below the vote: > > VOTE: > [ ] IDataProvider<I,T> [X] Iterator<IModel<T>> , drop model [X] Leave as is.
I like the idea that the standard usecase is somewhat "enforced" by the interface. I agree that the integer -> object mapping usecase is not common and could lead to performance problems. However, I'm somewhat torn between the last two options. Having that model method there was somewhat confusing in the first place when I was learning about it, but that could just be because generics weren't there to begin with to make it a bit more clear. If we go with option #2, then we're basically putting the "modelizing" logic onto the user. But, if we stick with it the way that it is, we're taking care of "modelizing" each item in the iterator for them (by using their method of course). If 99% of the people are going to have to write a method (the iterator<T> -> iterator<IModel<T>> transforming method), then why not just do that stuff for them and allow them a bit to customize it (like the model method)? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
