dev@woodstock.java.net

Re: DataProviders, JPA and Tables

From: Lilianne E. Blaze <lilianne_blaze_at_tlen.pl>
Date: Sun, 02 Sep 2007 00:38:51 +0200

Ok,
The easiest way was to use ObjectListDataProvider initialized to a
custom lazy List implemented so that for example on get(13) it loads
elements 10-19, sidestepping all the gory DP details. Of course such a
DP-List combo is read-only, but that doesn't matter in the scenario I
need it for (DP for admin views and summaries, one DAO for user-related
operations, one DAO for additional admin-related operations).
I have a nice little proof-of-concept project (JPA + HSQL + Spring +
Woodstock non-visual), I can try to 'tutorialize' it when I have time /
if there's a demand.

Greetings, Lilianne E. Blaze

Lilianne E. Blaze wrote:
> Hello,
> Either they're designed for something else entirely, or I'm missing
> something :/
> Consider the following scenario: a table with a list of users. Suppose
> it's up to 10.000 users, and it's page size is 25. Each row contains
> some basic data, plus some data which is calculated as needed and has to
> be done on object-by-object basis.
> Now, if I got it right, a "normal" DataProvider would require to get
> everything from a db, then sort it, then provide only the current 25. Is
> that correct?
> After reading the source I believe I can write, relatively easy, a
> DataProvider which, for example, when asked for 26th object lazily loads
> objects 25-50, doing sorting and limiting to page size on JPA's
> entityManager, while never actually containing more than visible at the
> moment. But I'm feeling I'm reinventing the wheel here, there should be
> support for such scenario, and I just can't see it. What am I missing here?
>
> Greetings, Lilianne E. Blaze
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>
>
>