The DataObject would need to be an argument to nextPage(), etc.
Basically this is doing the same thing you were suggesting, but it
gets rid of the Pager API.
Brent
On 11/8/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
I am probably missing something. If we stash the page size and number
in the
I am probably missing something. If we stash the page size and number
in the root data object how would that info get back to the command for
the next page request?
--
Kevin
Brent Daniel wrote:
Technically it's fine, but conceptually I'm not sure about passing a
command object to a pager. W
There would be no performance implication since each pager "next" or
"previous" operation requires a Command execution in either case.
Luciano Resende wrote:
Would this proposal implicate in performance degradation over a local
environment, compared with what we have today ? As the pager would
Technically it's fine, but conceptually I'm not sure about passing a
command object to a pager. What does it mean to page a command?
Another option would be to get rid of the Pager altogether. The only
state held in the Pager if you get rid of the Command is the page size
and current index. We co
Would this proposal implicate in performance degradation over a local
environment, compared with what we have today ? As the pager would have to
connect and execute the command every time the pager moves to the next or
previous pages ?
If we could come up with same interface for connected and dis
The RDB DAS currently has a simple paging capability that is implemented
by wrapping a Command. Here is a simple example:
// Build command to read all customers
Command readCustomers = das.createCommand("select * from
CUSTOMER order by ID");
// Create a pager with page s
