The following comment has been added to this issue:
Author: fabrizio giustina
Created: Mon, 15 Nov 2004 8:16 AM
Body:
We are talking about two different things here, I think you should open 2
separate reports for:
- refactoring of displaytag to use partial lists and to allow users to plug-in
different implementations of "data providers" (original subject for this
report, planned for 1.1)
- optimization which allows using a list without the need of iterating on each
row (partially implemented, can be done for 1.0)
---------------------------------------------------------------------
View this comment:
http://jira.codehaus.org/browse/DISPL-14?page=comments#action_26423
---------------------------------------------------------------------
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: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: DisplayTag
Components:
Paging/Sorting
Versions:
1.0 RC2
Assignee:
Reporter: fabrizio giustina
Created: Sat, 25 Sep 2004 4:39 AM
Updated: Mon, 15 Nov 2004 8:16 AM
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
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
