You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jan Kriesten <ja...@renitence.de> on 2008/04/23 09:46:03 UTC
Generics of IDataProvider
hi,
i stumbled over the generification of the IDataProvider, which IMHO doesn't make
sense as it is now:
public interface IDataProvider<T>
extends IDetachable
{
java.util.Iterator<T> iterator(int first, int count);
IModel<T> model(java.lang.Object object);
int size();
}
this would mean, that the Iterator + the IModel would contain the same type
information, making it impossible to use an Iterator over Integers and lookup
those Integer-ids within model to return a User e.g.
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Vitaly Tsaplin <vi...@gmail.com>.
The original design of the IDataProvider is essentially assuming
the separation of concepts. It has the 2 methods iterator () and model
(). This methods have different responsibilities. The generefication
is breaking the design. Why in this case you wouldn't create the model
for me automatically since you already have an object...
On Wed, Apr 23, 2008 at 11:50 AM, Jan Kriesten
<ja...@renitence.de> wrote:
>
> hi sebastiaan,
>
>
>
> > Hmm.... I seriously doubt that 1 round trip for the entire object is
> noticeably slower than 1 round trip for the PK's, even if you need to do
> some joins (assuming of course that you have proper indexes etc).
> >
>
> that might be - no question.
>
> but the programming model i have is somewhat simpler this way. to get into
> details, i have the following implementation of an IDataProvider:
>
> class FilterDataProvider[T <: AnyRef]( dao: IFilterDao[T], defaultSort:
> String, idLoader: Int => Option[T] )
> extends SortableDataProvider
> with IFilterStateLocator
> with IColumnVisibleState
>
> which encapsulates the handling of pk-lists and gets a dao and a loader
> function.
>
>
>
> > Furthermore, the performance penalty for objects NOT in de database is
> extremely large in your case (1 extra db round trip per object)!
> >
>
> well - based on that the id's come from the database that shouldn't happen
> - and if an id shouldn't exist any more, than this way at least it's made
> sure that no wrong data is shown any more.
>
> best regards, --- jan.
>
>
>
Re: Generics of IDataProvider
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
>> Furthermore, the performance penalty for objects NOT in de database is
>> extremely large in your case (1 extra db round trip per object)!
>
> well - based on that the id's come from the database that shouldn't
> happen - and if an id shouldn't exist any more, than this way at least
> it's made sure that no wrong data is shown any more.
This was a typo, sorry, I meant "NOT in the cache" instead of "NOT in
the database".
> best regards, --- jan.
Regards,
Sebastiaan
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi sebastiaan,
> Hmm.... I seriously doubt that 1 round trip for the entire object is
> noticeably slower than 1 round trip for the PK's, even if you need to do
> some joins (assuming of course that you have proper indexes etc).
that might be - no question.
but the programming model i have is somewhat simpler this way. to get into
details, i have the following implementation of an IDataProvider:
class FilterDataProvider[T <: AnyRef]( dao: IFilterDao[T], defaultSort: String,
idLoader: Int => Option[T] )
extends SortableDataProvider
with IFilterStateLocator
with IColumnVisibleState
which encapsulates the handling of pk-lists and gets a dao and a loader function.
> Furthermore, the performance penalty for objects NOT in de database is
> extremely large in your case (1 extra db round trip per object)!
well - based on that the id's come from the database that shouldn't happen - and
if an id shouldn't exist any more, than this way at least it's made sure that no
wrong data is shown any more.
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hmm.... I seriously doubt that 1 round trip for the entire object is
noticeably slower than 1 round trip for the PK's, even if you need to do
some joins (assuming of course that you have proper indexes etc).
Note that you ARE always querying lists... whether it's just the PK or
the whole row, the query (with where clause etc) must still be done.
Furthermore, the performance penalty for objects NOT in de database is
extremely large in your case (1 extra db round trip per object)!
Regards,
Sebastiaan
Jan Kriesten wrote:
>
> hi sebastiaan,
>
>> How does that work? You use the data provider to query the database
>> and then generate loadable detachable models based on the ids? Don't
>> you get a query per object that way?
>
> in fact, yes. but actually having cached the single objects it's more
> efficient this way than always querying lists.
>
> regards, --- jan.
>
>
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi sebastiaan,
> I'd still say that's a data provider which provides rss feeds not rss
> feed URLs. The fact that you want to retrieve them lazily seems an
> implementation detail to me, not something which should go in the
> interface of IDataProvider.
that's exactly the point - the dataprovider provides rssfeeds, not url's. but
the iterator provides feed urls - since they these come from different location
and have to fetched separately (e.g. from a database) - whereas the model is
build using rome e.g.
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Igor Vaynberg <ig...@gmail.com>.
i use anonymous ones all the time. currently i have >50
implementations of the interface
-igor
On Wed, Apr 23, 2008 at 5:02 AM, Jan Kriesten <ja...@renitence.de> wrote:
>
> hi johan,
>
> just out of curiosity - how many IDataProvider are you declaring within
> your typical application that adding a second type would cause such an
> increase of verbosity to your code?
>
> best regards, --- jan.
>
>
>
Re: Generics of IDataProvider
Posted by Sebastiaan van Erk <se...@sebster.com>.
Shouldn't it be pretty easy to replace IDataProvider with a super type
which takes both type parameters and defining IDataProvider<T> as
extends IWhatever<T, T>. Haven't thought about how this would break the
API and backwards compatability though. :-))
But I'm for dropping the model method. :-) At least we *know* that
breaks the API. ;-) But it would make much more sense to me, I always
found the model() method a bit strange...
Regards,
Sebastiaan
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.
Re: Generics of IDataProvider
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <pa...@inertiabev.com> 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.
>
>
Re: Generics of IDataProvider
Posted by Patrick Angeles <pa...@inertiabev.com>.
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.
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
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.
Re: Generics of IDataProvider
Posted by Maurice Marrink <ma...@gmail.com>.
On Wed, Apr 23, 2008 at 2:02 PM, Jan Kriesten <ja...@renitence.de> wrote:
>
> hi johan,
>
> just out of curiosity - how many IDataProvider are you declaring within
> your typical application that adding a second type would cause such an
> increase of verbosity to your code?
Trust me there are plenty :)
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).
Maurice
>
> best regards, --- jan.
>
>
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
just out of curiosity - how many IDataProvider are you declaring within your
typical application that adding a second type would cause such an increase of
verbosity to your code?
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Johan Compagner <jc...@gmail.com>.
you have a point yes.
But i guess the size() and iterator are still Dao operations and not really
wicket related stuff.
Because i wicket we really only use the mode() call. The iterator/model
combination is really done only through 1 class i think
then just wrappes all the things directly from the iterator.
But i guess it was more for clarity. Without the generics you cant say that
the iterator has to return Models..
So the pre 1.4 the api doesn't describe itself if we would do that.
I guess thats the big reason, but when igor is a wake i guess he has also
something to say :)
johan
On Wed, Apr 23, 2008 at 12:54 PM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> hi johan,
>
> thats true. But it wont be so verbose for everybody that uses the
> > Iterator
> > for just 1 type
> >
>
> well - the verbosity to add another type would be imho acceptable.
> generics
> _are_ verbose, that's the cost (though i'm not that affected using scala
> actually, the types are inferred by the compiler.
>
> So yes currently my vote is stil that you just use Object
> > But i dont know how that works out completely for the things you use
> > IDataprovider again..
> >
>
> if it should be like you say it'll be, why not just make IDataProvider
>
> public interface IDataProvider<T>
> extends IDetachable
> {
> java.util.Iterator<Model<T>> iterator(int first, int count);
> int size();
> }
>
> and drop the model completely? that would be consequent. (kidding)
>
>
> best regards, --- jan.
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> thats true. But it wont be so verbose for everybody that uses the Iterator
> for just 1 type
well - the verbosity to add another type would be imho acceptable. generics
_are_ verbose, that's the cost (though i'm not that affected using scala
actually, the types are inferred by the compiler.
> So yes currently my vote is stil that you just use Object
> But i dont know how that works out completely for the things you use
> IDataprovider again..
if it should be like you say it'll be, why not just make IDataProvider
public interface IDataProvider<T>
extends IDetachable
{
java.util.Iterator<Model<T>> iterator(int first, int count);
int size();
}
and drop the model completely? that would be consequent. (kidding)
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Johan Compagner <jc...@gmail.com>.
>
>
> IDataProvider<Object> my = new IDataProvider<Object>()
> >
>
> i must admin - that's a creative argument... drop generics for usecases
> like this.
yeah i did find it a great idea also ;)
>
>
> what is the point of differentiating between iterator + model when the
> iterator actually provides the type? to get it wrapped with Model() ??
>
> given
>
> public interface IDataProvider<T>
> extends IDetachable
> {
> java.util.Iterator<T> iterator(int first, int count);
> IModel<T> model(java.lang.Object object);
> int size();
> }
>
> you always get type T for object as argument from model, don't you?
yes i dont know currently why model(Object) is just Object as far as i know
it will be always the T of the Iterator..
Have to check this out.
>
>
> if i'd follow your example, i wouldn't gain anything of generics with
> wicket.
thats true. But it wont be so verbose for everybody that uses the Iterator
for just 1 type
This is really the first day that i did encounter this that the Iterator
returns something different then model returns in all the time that
IDataprovider exists...
So yes currently my vote is stil that you just use Object
But i dont know how that works out completely for the things you use
IDataprovider again..
johan
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> IDataProvider<Object> my = new IDataProvider<Object>()
i must admin - that's a creative argument... drop generics for usecases like this.
what is the point of differentiating between iterator + model when the iterator
actually provides the type? to get it wrapped with Model() ??
given
public interface IDataProvider<T>
extends IDetachable
{
java.util.Iterator<T> iterator(int first, int count);
IModel<T> model(java.lang.Object object);
int size();
}
you always get type T for object as argument from model, don't you?
if i'd follow your example, i wouldn't gain anything of generics with wicket.
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Johan Compagner <jc...@gmail.com>.
i mean more that maybe there are 1% that i can think of.
And still it is still pretty useable..
you just cant use generics for that case:
IDataProvider<Object> my = new IDataProvider<Object>()
{
private static final long serialVersionUID = 1L;
public void detach()
{
}
public int size()
{
return 0;
}
public IModel<Object> model(Object object)
{
Integer integer = (Integer)object;
return new YourModel<Object>(integer.toString());
}
public Iterator< ? extends Object> iterator(int first, int
count)
{
ArrayList<Integer> al = new ArrayList<Integer>();
return al.iterator();
}
};
works fine.
We dont discuss upfront all the kind of components what and how they should
be generified.
Many where done in 1 go and then see where it ends up by havinga few
Milestone builds where people can play with.
johan
On Wed, Apr 23, 2008 at 11:45 AM, Vitaly Tsaplin <vi...@gmail.com>
wrote:
> Hi people,
>
> My code is also suffering. I would vote for adding the second
> generic parameter.
>
> "then everbody has to create an iterator with 2 and 90+% of the cases it"
>
> 10% is a lot...
> By the way... the generification of IDataProvider... was it the one
> person decision or it was discussed somehow?
>
> Vitaly
>
> On Wed, Apr 23, 2008 at 11:26 AM, Sebastiaan van Erk
> <se...@sebster.com> wrote:
> >
> > Jan Kriesten wrote:
> >
> > >
> > > Hi Johan,
> > >
> > >
> > > > But how do you cache those objects?
> > > > Are those cached over all request so pretty much readonly ?
> > > >
> > >
> > > yes, they are.
> > >
> > > caching (and also marking as dirty) of objects is encapsulated within
> the
> > dao -
> > > so i do not have to worry much about this.
> > >
> > > also, IDataProvider isn't supposed to work only for Databases, right?
> > suppose
> > > the following (which i actually also have): i get a list of
> rssfeed-urls
> > from
> > > the database and within model i retrieve them - that's called
> 'separation
> > of
> > > concerns' which is also good programming style.
> > >
> >
> > I'd still say that's a data provider which provides rss feeds not rss
> feed
> > URLs. The fact that you want to retrieve them lazily seems an
> implementation
> > detail to me, not something which should go in the interface of
> > IDataProvider.
> >
> > Regards,
> > Sebastiaan
> >
> >
> > > best regards, --- jan.
> > >
> > >
> >
>
Re: Generics of IDataProvider
Posted by Rens Verhage <wi...@gmail.com>.
Why not create your own model that wraps an object's id with the actual
object? That way you can iterate over your wrapper objects without having
loaded the objects itself.
On Wed, Apr 23, 2008 at 11:45 AM, Vitaly Tsaplin <vi...@gmail.com>
wrote:
> Hi people,
>
> My code is also suffering. I would vote for adding the second
> generic parameter.
>
> "then everbody has to create an iterator with 2 and 90+% of the cases it"
>
> 10% is a lot...
> By the way... the generification of IDataProvider... was it the one
> person decision or it was discussed somehow?
>
> Vitaly
>
> On Wed, Apr 23, 2008 at 11:26 AM, Sebastiaan van Erk
> <se...@sebster.com> wrote:
> >
> > Jan Kriesten wrote:
> >
> > >
> > > Hi Johan,
> > >
> > >
> > > > But how do you cache those objects?
> > > > Are those cached over all request so pretty much readonly ?
> > > >
> > >
> > > yes, they are.
> > >
> > > caching (and also marking as dirty) of objects is encapsulated within
> the
> > dao -
> > > so i do not have to worry much about this.
> > >
> > > also, IDataProvider isn't supposed to work only for Databases, right?
> > suppose
> > > the following (which i actually also have): i get a list of
> rssfeed-urls
> > from
> > > the database and within model i retrieve them - that's called
> 'separation
> > of
> > > concerns' which is also good programming style.
> > >
> >
> > I'd still say that's a data provider which provides rss feeds not rss
> feed
> > URLs. The fact that you want to retrieve them lazily seems an
> implementation
> > detail to me, not something which should go in the interface of
> > IDataProvider.
> >
> > Regards,
> > Sebastiaan
> >
> >
> > > best regards, --- jan.
> > >
> > >
> >
>
Re: Generics of IDataProvider
Posted by Vitaly Tsaplin <vi...@gmail.com>.
Hi people,
My code is also suffering. I would vote for adding the second
generic parameter.
"then everbody has to create an iterator with 2 and 90+% of the cases it"
10% is a lot...
By the way... the generification of IDataProvider... was it the one
person decision or it was discussed somehow?
Vitaly
On Wed, Apr 23, 2008 at 11:26 AM, Sebastiaan van Erk
<se...@sebster.com> wrote:
>
> Jan Kriesten wrote:
>
> >
> > Hi Johan,
> >
> >
> > > But how do you cache those objects?
> > > Are those cached over all request so pretty much readonly ?
> > >
> >
> > yes, they are.
> >
> > caching (and also marking as dirty) of objects is encapsulated within the
> dao -
> > so i do not have to worry much about this.
> >
> > also, IDataProvider isn't supposed to work only for Databases, right?
> suppose
> > the following (which i actually also have): i get a list of rssfeed-urls
> from
> > the database and within model i retrieve them - that's called 'separation
> of
> > concerns' which is also good programming style.
> >
>
> I'd still say that's a data provider which provides rss feeds not rss feed
> URLs. The fact that you want to retrieve them lazily seems an implementation
> detail to me, not something which should go in the interface of
> IDataProvider.
>
> Regards,
> Sebastiaan
>
>
> > best regards, --- jan.
> >
> >
>
Re: Generics of IDataProvider
Posted by Sebastiaan van Erk <se...@sebster.com>.
Jan Kriesten wrote:
>
> Hi Johan,
>
>> But how do you cache those objects?
>> Are those cached over all request so pretty much readonly ?
>
> yes, they are.
>
> caching (and also marking as dirty) of objects is encapsulated within
> the dao -
> so i do not have to worry much about this.
>
> also, IDataProvider isn't supposed to work only for Databases, right?
> suppose
> the following (which i actually also have): i get a list of rssfeed-urls
> from
> the database and within model i retrieve them - that's called
> 'separation of
> concerns' which is also good programming style.
I'd still say that's a data provider which provides rss feeds not rss
feed URLs. The fact that you want to retrieve them lazily seems an
implementation detail to me, not something which should go in the
interface of IDataProvider.
Regards,
Sebastiaan
> best regards, --- jan.
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
Hi Johan,
> But how do you cache those objects?
> Are those cached over all request so pretty much readonly ?
yes, they are.
caching (and also marking as dirty) of objects is encapsulated within the dao -
so i do not have to worry much about this.
also, IDataProvider isn't supposed to work only for Databases, right? suppose
the following (which i actually also have): i get a list of rssfeed-urls from
the database and within model i retrieve them - that's called 'separation of
concerns' which is also good programming style.
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Johan Compagner <jc...@gmail.com>.
But how do you cache those objects?
Are those cached over all request so pretty much readonly ?
On Wed, Apr 23, 2008 at 10:48 AM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> hi sebastiaan,
>
> How does that work? You use the data provider to query the database and
> > then generate loadable detachable models based on the ids? Don't you get a
> > query per object that way?
> >
>
> in fact, yes. but actually having cached the single objects it's more
> efficient this way than always querying lists.
>
> regards, --- jan.
>
>
>
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi sebastiaan,
> How does that work? You use the data provider to query the database and
> then generate loadable detachable models based on the ids? Don't you get
> a query per object that way?
in fact, yes. but actually having cached the single objects it's more efficient
this way than always querying lists.
regards, --- jan.
Re: Generics of IDataProvider
Posted by Sebastiaan van Erk <se...@sebster.com>.
How does that work? You use the data provider to query the database and
then generate loadable detachable models based on the ids? Don't you get
a query per object that way?
I'd say the normal usecase is to query the data immediately.
Sebastiaan
Jan Kriesten wrote:
>
> Hi Johan,
>
>> then everbody has to create an iterator with 2 and 90+% of the cases it
>> would be
>> IDataProvider<Person,Person>
>>
>> thats not so nice :(
>
> 100% of my cases are IDataProvider<Integer,Implementation>
>
> --- jan.
Re: Generics of IDataProvider
Posted by Johan Compagner <jc...@gmail.com>.
you could argue that the IDataProvider should try to force a developer in
the right direction
and that it doesnt make a mistake that it shouldnt do :)
johan
On Wed, Apr 23, 2008 at 10:51 AM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> hi johan,
>
> Because if that is a model that does a query 1 by 1, trust me you can do
> > WAY
> > better to query them at once is a bit more complex query..
> >
>
> well, i don't want to argue the way my database access is.
>
> the point is, IDataProvider doesn't give the /option/ to do other than
> your way.
>
> best regards, --- jan.
>
>
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> Because if that is a model that does a query 1 by 1, trust me you can do WAY
> better to query them at once is a bit more complex query..
well, i don't want to argue the way my database access is.
the point is, IDataProvider doesn't give the /option/ to do other than your way.
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Johan Compagner <jc...@gmail.com>.
What model do you use to query those objects again then??
Because if that is a model that does a query 1 by 1, trust me you can do WAY
better to query them at once is a bit more complex query..
johan
On Wed, Apr 23, 2008 at 10:41 AM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> hi johan,
>
> really?
> > so you are selecting the PK's from a database
> > and then in the model 1 by 1 the Implementation???
> > That looks horrible inefficient
> >
>
> well, i may be odd in this respect, but i don't use hibernate et al but
> ibatis.
>
> so, selecting pk's from one table to get a list is definetely more
> efficient compared to do a complex join over a couple tables, building all
> objects and holding the whole object list in memory when only 15 are needed.
> wouldn't you agree?
>
> best regards, --- jan.
>
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> really?
> so you are selecting the PK's from a database
> and then in the model 1 by 1 the Implementation???
> That looks horrible inefficient
well, i may be odd in this respect, but i don't use hibernate et al but ibatis.
so, selecting pk's from one table to get a list is definetely more efficient
compared to do a complex join over a couple tables, building all objects and
holding the whole object list in memory when only 15 are needed. wouldn't you agree?
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Johan Compagner <jc...@gmail.com>.
really?
so you are selecting the PK's from a database
and then in the model 1 by 1 the Implementation???
That looks horrible inefficient
But maybe i dont see exactly what you have.
johan
On Wed, Apr 23, 2008 at 10:26 AM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> Hi Johan,
>
> then everbody has to create an iterator with 2 and 90+% of the cases it
> > would be
> > IDataProvider<Person,Person>
> >
> > thats not so nice :(
> >
>
> 100% of my cases are IDataProvider<Integer,Implementation>
>
> --- jan.
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
Hi Johan,
> then everbody has to create an iterator with 2 and 90+% of the cases it
> would be
> IDataProvider<Person,Person>
>
> thats not so nice :(
100% of my cases are IDataProvider<Integer,Implementation>
--- jan.
Re: Generics of IDataProvider
Posted by Johan Compagner <jc...@gmail.com>.
So you are saying you need this?
public interface IDataProvider<I,M>
extends IDetachable
{
java.util.Iterator<I> iterator(int first, int count);
IModel<M> model(I object);
int size();
}
then everbody has to create an iterator with 2 and 90+% of the cases it
would be
IDataProvider<Person,Person>
thats not so nice :(
johan
On Wed, Apr 23, 2008 at 9:46 AM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> hi,
>
> i stumbled over the generification of the IDataProvider, which IMHO
> doesn't make sense as it is now:
>
> public interface IDataProvider<T>
> extends IDetachable
> {
> java.util.Iterator<T> iterator(int first, int count);
> IModel<T> model(java.lang.Object object);
> int size();
> }
>
> this would mean, that the Iterator + the IModel would contain the same
> type information, making it impossible to use an Iterator over Integers and
> lookup those Integer-ids within model to return a User e.g.
>
> best regards, --- jan.
>
>
>
Re: Generics of IDataProvider
Posted by Johan Compagner <jc...@gmail.com>.
I also agree with igor, just start a vote on userlist.
I think in your usecase just use <Object> that works for you in 1.3,
yes no generics then for those cases. But that just doesnt complicate
things for 99% of all the other cases and the learning curve of the
interface
On 4/24/08, Igor Vaynberg <ig...@gmail.com> wrote:
> my point was that generics do not always work even when well defined,
> and sometimes you have to fallback on raw types.
>
> i look at this from the point of view of the framework developer: what
> is the easiest/simplest/most intuitive for most users. to me that is
> simply idataprovider<t>, i can look at it and immediately understand
> what <t> is. as you can see your proposal of <a,b> already required
> one explanation in this thread.
>
> so, from my point of view, you are asking me to complicate something
> to support your usecase, which i consider uncommon. you see where i am
> going with this? i cant justify it yet. i understand your usecase, but
> i also see ways of working around the limitation that are not too
> horrible, at least to me.
>
> that is why i suggested you start a vote/discussion on user list. you
> dont have to convince me that your way is better, you just have to
> convince me that the added complication is acceptable to our users. i
> have no problem changing my mind.
>
> -igor
>
>
> On Wed, Apr 23, 2008 at 10:41 PM, Jan Kriesten
> <ja...@renitence.de> wrote:
> >
> > hi igor,
> >
> >
> >
> > > i dont think we are cutting anything out. i am sure i can still come
> > > up with examples where generics do not work on component or model:
> > > such as a model that returns different-typed objects based on some
> > > condition.
> > >
> >
> > that's actually a quite different case than this, since here there are no
> > conditions to be evaluated.
> >
> >
> >
> > > in these cases you simply use the raw types and supress the
> > > warning. why can you not do that for your particular usecase?
> > >
> >
> > the point of using generics is to provide type safety and don't have to
> > assume types using casts. in my case it's breaking a structure i set up
> not
> > to have to cast when using generics. i'll send you a pm example how that
> > works for me.
> >
> > best regards, --- jan.
> >
> >
> >
>
Re: Generics of IDataProvider
Posted by Igor Vaynberg <ig...@gmail.com>.
my point was that generics do not always work even when well defined,
and sometimes you have to fallback on raw types.
i look at this from the point of view of the framework developer: what
is the easiest/simplest/most intuitive for most users. to me that is
simply idataprovider<t>, i can look at it and immediately understand
what <t> is. as you can see your proposal of <a,b> already required
one explanation in this thread.
so, from my point of view, you are asking me to complicate something
to support your usecase, which i consider uncommon. you see where i am
going with this? i cant justify it yet. i understand your usecase, but
i also see ways of working around the limitation that are not too
horrible, at least to me.
that is why i suggested you start a vote/discussion on user list. you
dont have to convince me that your way is better, you just have to
convince me that the added complication is acceptable to our users. i
have no problem changing my mind.
-igor
On Wed, Apr 23, 2008 at 10:41 PM, Jan Kriesten
<ja...@renitence.de> wrote:
>
> hi igor,
>
>
>
> > i dont think we are cutting anything out. i am sure i can still come
> > up with examples where generics do not work on component or model:
> > such as a model that returns different-typed objects based on some
> > condition.
> >
>
> that's actually a quite different case than this, since here there are no
> conditions to be evaluated.
>
>
>
> > in these cases you simply use the raw types and supress the
> > warning. why can you not do that for your particular usecase?
> >
>
> the point of using generics is to provide type safety and don't have to
> assume types using casts. in my case it's breaking a structure i set up not
> to have to cast when using generics. i'll send you a pm example how that
> works for me.
>
> best regards, --- jan.
>
>
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi igor,
> i dont think we are cutting anything out. i am sure i can still come
> up with examples where generics do not work on component or model:
> such as a model that returns different-typed objects based on some
> condition.
that's actually a quite different case than this, since here there are no
conditions to be evaluated.
> in these cases you simply use the raw types and supress the
> warning. why can you not do that for your particular usecase?
the point of using generics is to provide type safety and don't have to assume
types using casts. in my case it's breaking a structure i set up not to have to
cast when using generics. i'll send you a pm example how that works for me.
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Apr 23, 2008 at 10:04 PM, Jan Kriesten
<ja...@renitence.de> wrote:
>
> i might be the minority, but i find it rather strange to cut out options
> which were availabe in 1.3 and are dropped for the price of 6 bytes java
> code per IDataProvider in 1.4.
>
> generics with java are sometimes hell - they're verbose and not always very
> readable. but in this case this isn't actually a big problem. how much
> work/hassle would it cost you to actually change the fingerprint - no ten
> minutes with your 50 occurrences i suppose.
i dont think we are cutting anything out. i am sure i can still come
up with examples where generics do not work on component or model:
such as a model that returns different-typed objects based on some
condition. in these cases you simply use the raw types and supress the
warning. why can you not do that for your particular usecase?
-igor
>
> best regards, --- jan.
>
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi igor,
> sorry, but i dont buy this. models are not meant for factoring out
> business concerns, only crosscutting concerns. so you can have the
> model and the iterator wrapper delegate to the same util class that
> transforms the url string to the feed.
it doesn't make sense to do wrapping/transforming things twice - especially with
this example when url-calls are involved. database calls are cached, rss feeds
are freshly lookuped each time.
the method where the object is being build just happens to be named 'model' -
imho that has nothing to do with the model being used to do business concerns.
i'm arguing that the way IDataProvider is generified makes things worse in some
(maybe only my) cases then with v1.3x - and that shouldn't be.
there needs to be a way to only create a model once!
> new idataprovider<t>() { imodel<t> iterator(int first, int last) {
> return new modeliteratoradapter<t>(db.iterator(first, last)) {
> imodel<t> model(T t) { return new ldm(t); }}}
> is a lot uglier then the code you need now with a factored out model factory.
that's not that bad when you're using linebreaks actually. ;-) there are worse
examples with implementations needing to override inner structures with wicket.
>> - - have IDataProvider one generic for iterator and one for model.
> then 99% of people out there have to declare a redundant type. you are
> the minority here. that is my view of course.
i might be the minority, but i find it rather strange to cut out options which
were availabe in 1.3 and are dropped for the price of 6 bytes java code per
IDataProvider in 1.4.
generics with java are sometimes hell - they're verbose and not always very
readable. but in this case this isn't actually a big problem. how much
work/hassle would it cost you to actually change the fingerprint - no ten
minutes with your 50 occurrences i suppose.
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Igor Vaynberg <ig...@gmail.com>.
then people will complain that the util providers we provide implement
the default rather then the double one...
same problem
-igor
On Wed, Apr 23, 2008 at 10:17 PM, Jan Kriesten
<ja...@renitence.de> wrote:
>
> hi igor,
>
>
>
> >
> > > - - have IDataProvider one generic for iterator and one for model.
> > >
> > then 99% of people out there have to declare a redundant type.
> >
>
> one could actually have a utility interface to avoid redundant types:
>
> interface idefaultdataprovider<t> extends idataprovider<t,t>
>
> and everyone could be happy, not?
>
> best regards, --- jan.
>
>
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
hi igor,
>> - - have IDataProvider one generic for iterator and one for model.
> then 99% of people out there have to declare a redundant type.
one could actually have a utility interface to avoid redundant types:
interface idefaultdataprovider<t> extends idataprovider<t,t>
and everyone could be happy, not?
best regards, --- jan.
Re: Generics of IDataProvider
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Apr 23, 2008 at 11:18 AM, Jan Kriesten
<ja...@renitence.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> hi igor,
>
>
> | so if you want IDataProvider<A,B> A being iterator and B being model,
> | why not do the A->B transform in iterator() itself? obviously you are
> | caching the lookup anyways so there shouldnt be a performance hit...
>
> there are two cases with the iterator/model mixing into one or the other.
>
> a) separation of concerns
>
> given the rssfeed example: in the iterator there is a list of feedurls
> (strings)
> returned, which is a database lookup.
>
> within model, the strings are converted in the actual rssfeed.
>
> both are quite different tasks and could/are handled by different
> implementations.
sorry, but i dont buy this. models are not meant for factoring out
business concerns, only crosscutting concerns. so you can have the
model and the iterator wrapper delegate to the same util class that
transforms the url string to the feed.
> b) wrapping implementation details
>
> i have a common class which encpasulates id-lists and is provided a
> call-by-name
> method to just do the id-lookup. this is handled by the model
> implementation and
> isn't functional connected to the iterator at all.
>
> your suggestion is as i understand making a B from A within the iterator.
> so, i
> make a B from A in iterator, this object is then given to 'model' and there
> i
> make an IdLoadableDetachableModel from it, again? that just doesn't look
> right
> to me.
>
then your wrapper class can declare both generic types and to the
transformation internally.
> imho there are only two ways to go:
>
> - - drop 'model' and have iterator walk an IModel<B>
yes, that is definetely an option. the reason i did not go with this
is that it makes code uglier.
new idataprovider<t>() { imodel<t> iterator(int first, int last) {
return new modeliteratoradapter<t>(db.iterator(first, last)) {
imodel<t> model(T t) { return new ldm(t); }}}
is a lot uglier then the code you need now with a factored out model factory.
> - - have IDataProvider one generic for iterator and one for model.
then 99% of people out there have to declare a redundant type. you are
the minority here. that is my view of course. feel free to start a
survey/vote on the user list and see which way the users want it to
go, i wont have a problem changing my mind if thats what most users
want. strong opinions held weakly and all that :)
-igor
>
> best regards, --- jan.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFID32KLcYXCUxYsy4RAlU2AJ46YrGdkJi9mErdKnD/d7fdqiIt/QCg9ZqZ
> AO5QSPdd8K/mM5iEe4u0rKo=
> =9doM
> -----END PGP SIGNATURE-----
>
Re: Generics of IDataProvider
Posted by Jan Kriesten <ja...@renitence.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi igor,
| so if you want IDataProvider<A,B> A being iterator and B being model,
| why not do the A->B transform in iterator() itself? obviously you are
| caching the lookup anyways so there shouldnt be a performance hit...
there are two cases with the iterator/model mixing into one or the other.
a) separation of concerns
given the rssfeed example: in the iterator there is a list of feedurls (strings)
returned, which is a database lookup.
within model, the strings are converted in the actual rssfeed.
both are quite different tasks and could/are handled by different implementations.
b) wrapping implementation details
i have a common class which encpasulates id-lists and is provided a call-by-name
method to just do the id-lookup. this is handled by the model implementation and
isn't functional connected to the iterator at all.
your suggestion is as i understand making a B from A within the iterator. so, i
make a B from A in iterator, this object is then given to 'model' and there i
make an IdLoadableDetachableModel from it, again? that just doesn't look right
to me.
imho there are only two ways to go:
- - drop 'model' and have iterator walk an IModel<B>
- - have IDataProvider one generic for iterator and one for model.
best regards, --- jan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFID32KLcYXCUxYsy4RAlU2AJ46YrGdkJi9mErdKnD/d7fdqiIt/QCg9ZqZ
AO5QSPdd8K/mM5iEe4u0rKo=
=9doM
-----END PGP SIGNATURE-----
Re: Generics of IDataProvider
Posted by Igor Vaynberg <ig...@gmail.com>.
so if you want IDataProvider<A,B> A being iterator and B being model,
why not do the A->B transform in iterator() itself? obviously you are
caching the lookup anyways so there shouldnt be a performance hit...
-igor
On Wed, Apr 23, 2008 at 12:46 AM, Jan Kriesten
<ja...@renitence.de> wrote:
>
> hi,
>
> i stumbled over the generification of the IDataProvider, which IMHO doesn't
> make sense as it is now:
>
> public interface IDataProvider<T>
> extends IDetachable
> {
> java.util.Iterator<T> iterator(int first, int count);
> IModel<T> model(java.lang.Object object);
> int size();
> }
>
> this would mean, that the Iterator + the IModel would contain the same type
> information, making it impossible to use an Iterator over Integers and
> lookup those Integer-ids within model to return a User e.g.
>
> best regards, --- jan.
>
>
>