You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Przemysław Wojnowski <pr...@nask.pl> on 2009/06/24 17:01:11 UTC
T5: Grid#setupDataSource and GridDataSource
Hi!
Why Grid#setupDataSource() is calculating endIndex and not allowing for
GridDataSource to do it? Why GridDataSource#prepare method have
startIndex and endIndex parameters and not offset/limit pair?
I'm asking, because if GridDataSource could calculate endIndex (or use
limit instead) for itself, then there would be no need to call
getAvailableRows() before prepare(), which is a problem (at least IMHO).
Then Grid#setupDataSource() could look like this:
void setupDataSource()
{
cachingSource = new CachingDataSource(source);
int startIndex = (getCurrentPage()-1) * rowsPerPage;
cachingSource.prepare(startIndex, startIndex+rowsPerPage,
sortModel.getSortConstraints());
}
This would allow for single-call (those which receive number of
available rows, columns definitions, and columns values in one expensive
call) datasources to work.
Best regards,
Przemysław Wojnowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Grid#setupDataSource and GridDataSource
Posted by Przemysław Wojnowski <pr...@nask.pl>.
2009-06-25 Thiago H. de Paula Figueiredo:
> 2009/6/25 Przemysław Wojnowski <pr...@nask.pl>:
> > My point is that the current implementation of Grid#setupDataSource()
> > uses getAvailableRows() to calculate exact values for start and end
> > indices. Shouldn't this be responsibility of GridDataSource?
>
> Nice points in the whole message. :)
> One solution would be to create another interface, because Grid needs
> to know the number of available rows (regardless if before or after
> prepare()) and changing GridDataSource now would break backward
> compatibility quite badly.
> > IMHO there is no need for special value. It's just matter of the current
> > implementation of Grid#setupDataSource().
>
> You're suggesting the reversal of invokating order of prepare() and
> getAvailableRows()? I don't see any way of Grid working without
> getAvailableRows(), as it's needed to handle paging.
>
I think i was misunderstood. I don't want to change any interface,
especially GridDataSource. I'm just writing about current (Tapestry
5.2.0-snapshot) implementation of one method: Grid#setupDataSource().
The source code for this method is as follows:
--- code ---
void setupDataSource()
{
// TAP5-34: (...)
cachingSource = new CachingDataSource(source);
int availableRows = cachingSource.getAvailableRows();
if (availableRows == 0) return;
int maxPage = ((availableRows - 1) / rowsPerPage) + 1;
// This captures when the number of rows has decreased,
typically due to deletions.
int effectiveCurrentPage = getCurrentPage();
if (effectiveCurrentPage > maxPage)
effectiveCurrentPage = maxPage;
int startIndex = (effectiveCurrentPage - 1) * rowsPerPage;
int endIndex = Math.min(startIndex + rowsPerPage - 1,
availableRows - 1);
dataModel = null;
cachingSource.prepare(startIndex, endIndex,
sortModel.getSortConstraints());
}
--- code ---
Here getAvailableRows() is used only to calculate start and end indices.
But their exact values (taking into account decreased number of rows)
can (maybe should?) be calculated in implementation of GridDataSource
and then implementation of Grid#setupDataSource() could look like this:
--- code ---
void setupDataSource()
{
cachingSource = new CachingDataSource(source);
int startIndex = (getCurrentPage()-1) * rowsPerPage;
cachingSource.prepare(startIndex, startIndex+rowsPerPage,
sortModel.getSortConstraints());
}
--- code ---
Grid still uses getAvailableRows() but not in setupDataSource() method,
and not before prepare().
Maybe I misunderstood something or not seeing something. In that case I
would like to know what. :-)
Best regards and thanks for response!
Przemysław Wojnowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Grid#setupDataSource and GridDataSource
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
2009/6/25 Przemysław Wojnowski <pr...@nask.pl>:
> My point is that the current implementation of Grid#setupDataSource()
> uses getAvailableRows() to calculate exact values for start and end
> indices. Shouldn't this be responsibility of GridDataSource?
Nice points in the whole message. :)
One solution would be to create another interface, because Grid needs
to know the number of available rows (regardless if before or after
prepare()) and changing GridDataSource now would break backward
compatibility quite badly.
> IMHO there is no need for special value. It's just matter of the current
> implementation of Grid#setupDataSource().
You're suggesting the reversal of invokating order of prepare() and
getAvailableRows()? I don't see any way of Grid working without
getAvailableRows(), as it's needed to handle paging.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Grid#setupDataSource and GridDataSource
Posted by Przemysław Wojnowski <pr...@nask.pl>.
Dnia 2009-06-24, śro o godzinie 12:19 -0300, Thiago H. de Paula
Figueiredo pisze:
> > Why Grid#setupDataSource() is calculating endIndex and not allowing for
> > GridDataSource to do it? Why GridDataSource#prepare method have
> > startIndex and endIndex parameters and not offset/limit pair?
>
> As offset = startIndex and limit = endIndex - startIndex + 1, I think
> their interchangeable for most scenarios.
>
> > I'm asking, because if GridDataSource could calculate endIndex (or use
> > limit instead) for itself, then there would be no need to call
> > getAvailableRows() before prepare(), which is a problem (at least IMHO).
>
> I guess getAvailableRows() is used for calculating the number of pages
> and then display the pager.
When pager is used, then GDS#prepare() was already called, so
getAvaialbleRows() can return correct value.
My point is that the current implementation of Grid#setupDataSource()
uses getAvailableRows() to calculate exact values for start and end
indices. Shouldn't this be responsibility of GridDataSource?
Grid#setupDataSource() could pass just "logical" (exact available rows
would be calculated by GDS) values calculated as I wrote in previous
post.
IMHO this would also allow for GDS to handle rows deletions for itself.
>
> > This would allow for single-call (those which receive number of
> > available rows, columns definitions, and columns values in one expensive
> > call) datasources to work.
>
> Please file a JIRA about this. Maybe we could use some special return
> value in GridDataSource.getAvailableRows() to indicate that it is not
> available yet and then call it again after GridDataSource.prepare(),
> thus solving your problem.
IMHO there is no need for special value. It's just matter of the current
implementation of Grid#setupDataSource().
For now, to make Grid working with single-call GridDataSource, I had to
copy Grid.java only to replace setupDataSource().
Best regards,
Przemysław Wojnowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Grid#setupDataSource and GridDataSource
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
2009/6/24 Przemysław Wojnowski <pr...@nask.pl>:
> Hi!
Hi!
> Why Grid#setupDataSource() is calculating endIndex and not allowing for
> GridDataSource to do it? Why GridDataSource#prepare method have
> startIndex and endIndex parameters and not offset/limit pair?
As offset = startIndex and limit = endIndex - startIndex + 1, I think
their interchangeable for most scenarios.
> I'm asking, because if GridDataSource could calculate endIndex (or use
> limit instead) for itself, then there would be no need to call
> getAvailableRows() before prepare(), which is a problem (at least IMHO).
I guess getAvailableRows() is used for calculating the number of pages
and then display the pager.
> This would allow for single-call (those which receive number of
> available rows, columns definitions, and columns values in one expensive
> call) datasources to work.
Please file a JIRA about this. Maybe we could use some special return
value in GridDataSource.getAvailableRows() to indicate that it is not
available yet and then call it again after GridDataSource.prepare(),
thus solving your problem.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org