Feature Requests item #872183, was opened at 2004-01-07 16:34
Message generated for change (Comment added) made by ianbdev
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=536616&aid=872183&group_id=73068
Category: main taglib
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Barnett (ianbdev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Increase efficiency of paging using a list subset
Initial Comment:
We encountered a situation where we had to support a
query that resulted in 1000's or rows (I wouldn't ask why
it's a very long story).
Loading all this from the DB into the application server
memory was terribly wasteful and resource hungry.
We came up with a db list paging solution (borrowing a
suggestion from askTom and incorporating in our app)
that allowed us to retrieve just one page of records from
a given page number (with a known page size).
The problem was than to get DisplayTag to take the
abbreviated list of just 100 records and display them and
continue to manage the page navigation correctly (i.e.
to show that we are at page 5 of approx 66 pages
where there are 6650 records total).
We managed to do this with some changes to the
DisplayTag code (see attached).
The application is responsible for getting the abbreviated
list of records and the total list size and passing it to the
table tag.
If this can be implemented in the display tag project we
would be most appreciative. Hopefully others will find the
feature useful as well.
----------------------------------------------------------------------
>Comment By: Ian Barnett (ianbdev)
Date: 2004-01-08 08:03
Message:
Logged In: YES
user_id=461701
OK - I get it - the JSP code tags are being interpreted here
(doh) - anyway just put the value for the full list size in this
parameter.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2004-01-08 07:58
Message:
Logged In: NO
oops - the jsp code didn't show up... trying again (just the
new parameter part)...
virtualSize="<%= ((Integer)request.getAttribute
(CodeListAction.CODE_LIST_SIZE_KEY)).toString() %>"
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2004-01-08 07:54
Message:
Logged In: NO
Sorry - forgot to mention the code is based off the 1.0.b2
codebase if you want to do the diff.
I should also point out that the code is still hot off the
development gridle. It has been tested to ensure the paging
navigation works with the abbreviated list and it should work
normally (i.e. with full lists) if the virtualSize parameter (i'm
certainly not married to this name - suggestion box is open...)
is not set or set to -1.
Since my knowledge of the entire DisplayTag codebase is
limited I cannot say for certain that there are no other ill side
effects of this change.
I can say that certain things will definitely not work with the
current assumptions in the DisplayTag codebase (i.e. that the
code always has access to the full list).
For instance you cannot sort the full list in DisplayTag if you
only have part of it (the effect would be to sort the page
only). A more comprehensive approach might say "if the
application is trying to sort the full list then don't even
attempt it - just action the sort url with the sort column
parameter and the let the application handle the full list
sorting...). I have not coded for that case.
Of interest might be the code snippets that do the server side
work (we are using JSPs, Struts Actions, and Oracle DB).
JSP:
<display:table class="list" name="<%=
CodeListAction.CODE_LIST_KEY %>" id="row" pageSize="20"
virtualSize="<%= ((Integer)request.getAttribute
(CodeListAction.CODE_LIST_SIZE_KEY)).toString() %>"
requestURI="codelist.do" sort="list">
(the request attribute should probably just be stored as a
string to stop the excess coding here)
ACTION:
// Get the page number requested
int page = 1;
int size = 20;
Enumeration paramNames = request.getParameterNames
();
while (paramNames.hasMoreElements()) {
String name = (String)paramNames.nextElement();
if (name != null && name.startsWith("d-") &&
name.endsWith("-p")) {
String pageValue = request.getParameter(name);
if (pageValue != null) {
page = Integer.parseInt(pageValue);
}
}
}
(suggestions welcome for a better way to decipher the
DisplayTag parameter prefix...Also the page size may vary in
the JSP so this value should be placed in the request -
DisplayTag could add the pagesize into the request url if the
virtualSize parameter is being used)
DB:
There are a number of ways to handle this bit - stored
procedures, two db calls, cached data, etc. For now we are
just making two calls - one to get the list size and one to get
the page of data we need - we could probably check the
where clause of the query for any filtering changes before
getting the size again if we know the user is still paging
through the same list range - but that'll come later...;-)
This bit applies to Oracle - you'll need to come up with your
own version for other DB's (I got this from askTom):
The paging sql code should wrap your own query as a
complete inner query):
select * from (
select query.*, rownum rnum from (
your complete query goes here....
) query where rownum <= (:pagingNo*:pagingSize)
) where rnum >= ((:pagingNo-1)*:pagingSize)+1 order by rnum
askTom also suggests using the FIRST_ROWS hint if you have
an excessively large number of rows (search for
subject "getting rows N through M of a result set")
BTW: I forgot to mention before but big thanks to the
DisplayTag development crew - we just love this library!
----------------------------------------------------------------------
Comment By: Tim McCune (javajedi)
Date: 2004-01-08 00:50
Message:
Logged In: YES
user_id=62441
Awesome. I was going to do this, but didn't in the hopes
that someone else would first. :) It seemed like a very
obvious needed fix to displaytag, but looked like it
wouldn't be trivial to implement. I didn't look through the
patch very closely since it wasn't submitted as a diff, but
if it works, I would second the hope that it can be pulled
back into the main source base.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=536616&aid=872183&group_id=73068
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
