and then we have to provide SortableDataProvider<T> and
SortableUberDataProvider<A,B> ? and components that currently depend
on the sortable impl of dataprovider (DataTable, etc) also have to
come in two flavors?
-igor
On Thu, Apr 24, 2008 at 4:16 PM, Patrick Angeles <[EMAIL PROTECTED]> wrote:
>
> if all that had to be done was satisfy this usecase while keeping the API
> from breaking, we could do:
>
> public interface IUberDataProvider<I,M>
> extends IDetachable
> {
> java.util.Iterator iterator(int first, int count);
>
> IModel<M> model(I object);
> int size();
> }
>
> public interface IDataProvider<M>
> extends IUberDataProvider<M,M>;
>
>
>
>
>
> Jan Kriesten wrote:
> >
> >
> > hi maurice,
> >
> >> Trust me there are plenty :)
> >
> > i assume your talking about an increase of 100 occurences * 6 bytes = 600
> > bytes
> > increased (unnecessary) code. ;-)
> >
> >> I do like the idea of dropping the model method but am not sure
> >> Martijn wil sanction such an api break, since 1.4 is supposed to be a
> >> drop in replacement (well almost).
> >
> > if the model would be dropped - i could wrap generation of the model
> > without
> > much hassle, too, since all i do in model is
> >
> > def model( obj: AnyRef ): IModel = new IdLoadableDetachableModel(
> > obj.asInstanceOf[Int] ) { @Override protected def load: T = idLoader(
> > getId ).get }
> >
> > so wrapping the iterator returned by the dao wouldn't be a big thing.
> >
> >
> > as it is now - the iterator has to be of type T, too - and that just
> > simply
> > doesn't work for me now.
> >
> > best regards, --- jan.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Generics-of-IDataProvider-tp16850090p16858137.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
