Bugs item #950819, was opened at 2004-05-09 16:26 Message generated for change (Comment added) made by ralfhauser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=536613&aid=950819&group_id=73068
Category: main tag library Group: after 1.0 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Wilson (mlavwilson) Assigned to: Nobody/Anonymous (nobody) Summary: Paging and sorting is done in the JVM:( Initial Comment: 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] ---------------------------------------------------------------------- Comment By: Ralf Hauser (ralfhauser) Date: 2004-05-11 04:42 Message: Logged In: YES user_id=266141 see also https://sourceforge.net/tracker/?func=detail&atid=536616&aid=951204&group_id=73068 ---------------------------------------------------------------------- Comment By: Matthew Wilson (mlavwilson) Date: 2004-05-11 00:10 Message: 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? ---------------------------------------------------------------------- Comment By: Scott McCrory (smccrory) Date: 2004-05-10 21:10 Message: 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). ---------------------------------------------------------------------- Comment By: Scott McCrory (smccrory) Date: 2004-05-10 21:09 Message: 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). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=536613&aid=950819&group_id=73068 ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
