The following comment has been added to this issue:
Author: James Schopp
Created: Wed, 24 Nov 2004 1:23 PM
Body:
Ivan,
Regarding the point about showing the total list size:
* we have overridden the "messages" shown to the user, so instead of saying
"Records 1-10 of 100", we say "Records 1-10. More Available", and the "Last"
button says "More". Then, once we have finally reached the end (our lists have
a flag that tell us this), we then switch back to the "normal" messages taht
you would expect.
Regarding your comment "representing the data as iterable list exposes too
much semantics to the DT":
* the truth is actually the opposite: DT has absolutely no knowledge that
my lists are "lazy loading" the data - it only knows it has "a list"! On the
contrary, adding "Data Providers" does mean modifying DT substantially. The
reason that I require patches to DT is because of all the iterations DT makes
over the entire list (causing all the data to be loaded everytime... the worst
case scenario!). IF DT did not iterate so often over the entire list, then the
solution would work perfectly (and fixing this is something that benefits
EVERYONE, since DT really should iterate just once over minimal necessary
records - no more, no less)
I imagine that the Data Provider strategy must have the same problem too,
right? I mean, if DT asks for the 1000th record, you have to fetch it from the
DB, so the multiple iterations means multiple DD calls.
IN ANY CASE: my "smart list" solution is *not* mutually exclusive to the Data
Provider solution. Our environment uses the smart lists in other environments
other than just web-based tables, so we solve the problem in those environments
using this same technology. The Data Provider would be a perfect solution for
us as well if we didn't have to support these other environments.
regards,
james
---------------------------------------------------------------------
View this comment:
http://jira.codehaus.org/browse/DISPL-14?page=comments#action_27125
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/browse/DISPL-14
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DISPL-14
Summary: Smart Paging
Type: Improvement
Status: Open
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: DisplayTag
Components:
Paging/Sorting
Versions:
1.0 RC2
Assignee: fabrizio giustina
Reporter: fabrizio giustina
Created: Sat, 25 Sep 2004 4:39 AM
Updated: Wed, 24 Nov 2004 1:23 PM
Description:
====
imported from sf tracker
id 1026408
submitted by Ivan Markov - ivan_markov
http://sourceforge.net/tracker/index.php?func=detail&group_id=73068&atid=536613&aid=1026408
====
Smart Paging
------------
Smart paging refers to the ability of DT to deal with large lists of data. The
problem with the current DT approach is that:
a) The whole (potentially large) list of data has to be created for the DT tag,
occupying lots of memory.
b) If the list contains 1000s of records, populated with data from a SQL Server
(99% of the cases, I would say), you have huge network traffic between the
webapp and the server. Our code is especially useful for servers like Oracle &
MySQL which have built-in means to return only a subset of DB cursor's content.
There's one solution + one enhancement on the forums already (issue #1013526),
so why a third one?
We didn't like in the earlier proposal that it deals with intercepting DT's
request and parsing DT's request parameters, which seems a bit hacky. Also, we
avoid the complications of parsing parameters when there is > 1 table tag on
the page. Not to mention that the older proposal does not deal with full list
sorting, or does it?
Instead, we introduced a new interface, DataProvider. It has two methods:
- List getData(int unsortedOffset, int unsortedLength, int recordOffset, int
pageSize, String sortedColumnName, boolean sortOrderAscending);
- int getDataCount();
The first two parameters unsortedOffset & unsortedLength are only needed for
supporting DT's setOffset()/setLength() features.
In our patch, DataProvider is used as a "callback" into user's code. The user
is supposed to implement the two methods of this interface.
The code in TableTag and its supporting classes is changed in a way that, for
each response where DT is rendered,
a) One call is issued to DataProvider.getDataCount(), which retrieves the total
number of rows in the data set (needed for DT to calculate the number of pages).
b) One call is issued to DataProvider.getData(), with the current page, page
size & sorting info.
A sample implementation of user-supplied JDBC DataProvider follows, in
pseudocode. Some JDBC exception handling stuff omitted.
<%
request.setAttribute("list", new DataProvider() {
List getData(int unsortedOffset, int unsortedLength, int recordOffset, int
pageSize, String sortedColumnName, boolean sortOrderAscending) {
Connection con = <app-specific way to get connection>;
PreparedStatement ps = con.prepareStatement("SELECT * FROM MyTable
ORDER BY ? LIMIT ?, ?"):
ps.setString(1, sortedColumnName);
ps.setInt(2, recordOffset);
ps.setInt(3, pageSize);
//etc..
ResultSet rs = con.execute();
return <app-specific way of getting List from ResultSet; Maybe use
RowSet instead of List?>;
}
int getDataCount() {
Connection con = <app-specific way to get connection>;
PreparedStatement ps = con.prepareStatement("SELECT count(*)
FROM MyTable"):
ResultSet rs = con.execute();
rs.next();
return rs.getInt(1);
}
});
%>
(DataProvider implementation code can be moved to Struts Controller/Action,
depending on the MVC framework used, in order not to polute the JSP code with
Java scriptlets.)
Smart Paging Compatibility
--------------------------
We tried to change DT's code so that all older code to continue to work.
If user has provided an old-style List containing all the data, DT will
automatically wrap it with a ListDataProvider.
Current DT functionality (full-list sorting, decorations, multiple tables per
page, etc.) is supported, except for these two cases:
a) Full list(not page) sorting by a decorated column - sorting is done without
regarding the decorator.
b) Full list sorting by a column with no "property" attribute (static or
implicit object call via servlet) - no sorting is performed at all.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
