[ http://jira.codehaus.org/browse/DISPL-131?page=all ]
fabrizio giustina closed DISPL-131:
-----------------------------------
Resolution: Duplicate
see DISPL-129
> 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
-------------------------------------------------------
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
