[ http://jira.codehaus.org/browse/DISPL-14?page=all ]
     
fabrizio giustina closed DISPL-14:
----------------------------------

     Resolution: Duplicate
    Fix Version: 1.1

see DISPL-122 and DISPL-129

> Smart Paging
> ------------
>
>          Key: DISPL-14
>          URL: http://jira.codehaus.org/browse/DISPL-14
>      Project: DisplayTag
>         Type: Improvement

>   Components: Paging/Sorting
>     Versions: 1.0 RC2
>     Reporter: fabrizio giustina
>     Assignee: fabrizio giustina
>      Fix For: 1.1
>  Attachments: OptimizedPaginationIteration.1.0-RC2.zip, 
> OptimizedPaginationIteration.zip, 
> displaytag-1.0-rc1-pdf_paging_exclude_columnhref.diff, dt_pdf_paging.diff, 
> dt_pdf_paging_java.zip
>
>
> ====
> 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.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
displaytag-devel mailing list
displaytag-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/displaytag-devel

Reply via email to