[ http://jira.codehaus.org/browse/DISPL-131?page=comments#action_45200 ]
fabrizio giustina commented on DISPL-131: ----------------------------------------- I had a look at the patch by Jean-Baptiste, and it looks good. I was already going add an interface which could be used instead of separate parameters. I will merge that with the current cvs code, trying to adapt the already committed patch by David in order to use a PaginatedList implementation internally. > Paging and sorting handled externally - valuelist pattern > --------------------------------------------------------- > > Key: DISPL-131 > URL: http://jira.codehaus.org/browse/DISPL-131 > Project: DisplayTag > Type: Improvement > Components: Paging/Sorting > Versions: 1.0 RC2 > Reporter: fabrizio giustina > Fix For: 1.1 > Attachments: externalSort.zip > > > ==== > imported from sf tracker > id 950819 > submitted by Matthew Wilson - mlavwilson > http://sourceforge.net/support/tracker.php?aid=950819 > ==== > If you work with large amounts of data a web site using > this product does not scale well, or in most casese at all. > I have a sf project: > http://mlavwilson.sourceforge.net/vlh/. I have > implemented the ValueList Pattern, and have a few tag > libs. You have a much richer set of taglibs. If you are > interested in using the ValueListHandler service as an > implementation to handel the paging and sorting.. and > data retrieval. Contact me. [EMAIL PROTECTED] > ===== > Date: 2004-09-07 03:52 > Sender: ianbdev > Logged In: YES > user_id=461701 > Hello, > I posted the 872183 request. > Since then we've come up with an alternate approach. > See [ 1023387 ] Pagination - use subList instead of iterating > all records. > If this change is implemented then you can implement a List > object that overrides the subList method of the List interface. > This would allow you to limit database/datasource accesses > to obtain just the few page records required for the page > being displayed. > No other changes to display tag are required. > Date: 2004-05-27 15:48 > Sender: smccrory > Logged In: YES > user_id=20779 > You're right. I recommend closing this issue 950819 as well > as 951204 as duplicates, then increasing the priority > on "master" issue 872183. I'd also recommend cross- > referencing 950819 and 951204 from *872183*. I'd do this > for you but I don't think I have permissions to admin issues. > I'm interested enough in this feature that I might be willing > to > help implement it. Please contact me directly if you're > interested. > Date: 2004-05-27 15:13 > Sender: carlossg > Logged In: YES > user_id=792979 > This has been already pointed out in RFE 872183 > Date: 2004-05-15 19:50 > Sender: mlavwilson > Logged In: YES > user_id=531802 > Like you mentioned earlier: My reccomendation is to allow > your tag to take both a list and a paging/sorting info. So > instead of: > <display:table name="sessionScope.test" pagesize="10"> > you would have: > <display:table name="sessionScope.test" > pageInfo="sessionScope.pageInfoBean"> > Where pageInfoBean is an interface. This would allow allow > me to use your great tags without tying the two products > together. > Date: 2004-05-14 04:54 > Sender: smccrory > Logged In: YES > user_id=20779 > Sounds good, and please keep it easy to use, i.e. don't make > the user create their own ValueList adapters for the most > fundamental use of it - providing DisplayTag a partial list and > a total (full list) record count. Thanks in advance - you guys > are doing great and really useful work. > Date: 2004-05-14 00:17 > Sender: fgiustAccepting Donations > Logged In: YES > user_id=798060 > after 1.0. > We'll surely need to enhance displaytag to make it handle > partial lists, I will look at the ValueList pattern to implement > it > (but only supplying interfaces without any jdbc > implementation...) > Date: 2004-05-11 04:42 > Sender: ralfhauserAccepting Donations > Logged In: YES > user_id=266141 > see also > https://sourceforge.net/tracker/?func=detail&atid=536616&aid=9512 > 04&group_id=73068 > Date: 2004-05-11 00:10 > Sender: mlavwilson > Logged In: YES > user_id=531802 > "..looked at vlh, and it appears to (at least initially) depend > on direct JDBC. This wouldn't work in environments that have > business and data..." > The ValueListService currently ships with only a few adapters, > the one you mention is the DefaultDynAdapter > (http://cvs.sourceforge.net/viewcvs.py/mlavwilson/vlh/src/jav > a/net/mlw/vlh/adapter/dyna/DefaultDynAdapter.java? > rev=1.3&view=auto). Like you notice this adapter is just > about usesless, because in a real work application you would > go through the business layer, which would go to the DAO > layer which would go... This is why the ValueListHandler is > designed around the ValueListAdapter > (http://cvs.sourceforge.net/viewcvs.py/mlavwilson/vlh/src/jav > a/net/mlw/vlh/ValueListAdapter.java?rev=1.2&view=auto). > This base class (Should be an interface, i am refactoring that > now) can be extended to support any type of data retrieval > needed. > Another standard Adapter is the DirectoryReaderValueList > (http://cvs.sourceforge.net/viewcvs.py/mlavwilson/vlh/src/jav > a/net/mlw/vlh/adapter/file/DirectoryReaderValueList.java? > rev=1.1&view=auto), this adapter returns a ValueList of > FileInfo pojos. > The ValueListService returns a > "ValueList" > (http://cvs.sourceforge.net/viewcvs.py/mlavwilson/vlh/src/jav > a/net/mlw/vlh/ValueList.java?rev=1.1&view=auto). A > ValueList contains a ValueListInfo > (http://cvs.sourceforge.net/viewcvs.py/mlavwilson/vlh/src/jav > a/net/mlw/vlh/ValueListInfo.java?rev=1.5&view=auto) which > contains the paging and sorting information. > "Plus, we > would NOT be marrying the visual tier with the persistence > technology other than having to write new method(s) to get > the total query result count(s)." > This is the job of the ValueListAdapter i discussed above. > Does this all make sence? > Date: 2004-05-10 21:10 > Sender: smccrory > Logged In: YES > user_id=20779 > I looked at vlh, and it appears to (at least initially) depend > on > direct JDBC. This wouldn't work in environments that have > business and data access layer between the view and the > persistence tiers. Once you start talking about getting data > via SOAP, EJBs, O/R tools, etc. you're up a creek... > A better approach, I think, would be to provide DisplayTag > not just a list (which may be of only part of the complete > result set), but also a total record count and the page it's > currently on. Then, whenever a user clicks "Next" or a page > number, our applications could strip off the number, > (beginning row number, etc.) and pass that down to the DAO > layer to limit the number of rows returned. Our DAOs might > have to bang the DB twice (once to get a total count and > another to return the partial set), but I'd imagine this would > be much more efficient than returning the whole set. Plus, we > would NOT be marrying the visual tier with the persistence > technology other than having to write new method(s) to get > the total query result count(s). > Date: 2004-05-10 21:09 > Sender: smccrory > Logged In: YES > user_id=20779 > I looked at vlh, and it appears to (at least initially) depend > on > direct JDBC. This wouldn't work in environments that have > business and data access layer between the view and the > persistence tiers. Once you start talking about getting data > via SOAP, EJBs, O/R tools, etc. you're up a creek... > A better approach, I think, would be to provide DisplayTag > not just a list (which may be of only part of the complete > result set), but also a total record count and the page it's > currently on. Then, whenever a user clicks "Next" or a page > number, our applications could strip off the number, > (beginning row number, etc.) and pass that down to the DAO > layer to limit the number of rows returned. Our DAOs might > have to bang the DB twice (once to get a total count and > another to return the partial set), but I'd imagine this would > be much more efficient than returning the whole set. Plus, we > would NOT be marrying the visual tier with the persistence > technology other than having to write new method(s) to get > the total query result count(s). -- 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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ displaytag-devel mailing list displaytag-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/displaytag-devel
