Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: 1.0 RC2
-
Fix Version/s: 1.1
-
Component/s: Paging/Sorting
-
Labels:None
Description
====
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. mlavwilson@hotmail.com.
=====
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).
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. mlavwilson@hotmail.com.
=====
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).
