You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Brian Cochran <br...@bricom.com> on 2001/11/16 00:31:58 UTC
Other possible tools for paging collections
Writing paging (i.e. next, previous, etc) iterators can be a real pain to do
correctly (at least it is for me).
Looking at the petstore, they seem to wuss out on doing it nice. It occured
to me that there are a few options as far as doing iteration over pages.
1) retrieve all results and keep them in memory (in a session var i guess)
while the user pages through them.
2) go to the db every time.
3) JDBC 2.0 allows scrollable recordsets so you could have time-out-able
recordsets that essentially close themselves
on a time expiration and may reopen themselves if needed. (May be some
nasty concurrency problems with this)
4) create a hybrid that will cache some of the pages and go to the database
if needed. Maybe be able to configure
the number of pages to cache. Really cool would be able to change it
dynamically.
5) somebody elses neat idea
But whatever is used there is the basic principle of getEntities(int index,
int span). So what do you guys think about
a series of paging iterators that looked something like this.
abstract class PagingIterator
abstract List getEntities(int startIndex, int span)
int getPage()
void setPage(int page)
boolean hasNextPage()
void nextPage()
boolean hasPreviousPage()
void previousPage()
class RequeryPagingIterator extends PagingIterator // like the petstore
abstract List getEntities(int startIndex, int span)
class CacheingPagingIterator extends PaginingIterator // good for a lot
of smaller datasets
List _AllEntities = null;
List getEntities(int startIndex, int span){
if(_AllEntities == null){
getAllEntities();
}
int stopIndex = max(startIndex + span, _AllEntities.size() - 1);
return _AllEntites.subList(startIndex, stopIndex);
}
class MultiplePageCachingPagingIterator extends PagingIterator // great
little combination
...
class ResultSetPagingIterator extends PagingIterator { // little new to
JDBC 2 so not sure bout this (suggestions)
... // used with JDBC 2.0
}
The cool thing is the tags on the JSP's all work with PagingIterator so
there is no need for the page to know how
the paging is implemented.
Some other things. Currently i have a messy implementation of this running
inside struts. Works ok. but basically some
of the challenges include
1) knowing when the query is new and when its navigation. currently I check
for the presense of a navigate in
the request params.
2) where and when to stash the iterator. Currently I'm stashing it in the
session using some other custom tags.
3) should the getEntities thing be done as an interface instead of an
abstract method? e.g
new SomePagingIterator(ChunkableRetriever c) where ChunkableRetriever has
a method getEntities(int start, int span)
3) how do you cleanly handle errors (I suck at error handeling in JSPs)
Here's an example how its being used.
ItemsByCategoryPagingIterator extends RequeryPagingIterator {
String _CategoryId = null;
Collection getEntities(int start, int span) throws SomeException {
Collection col = null;
try {
col = itemsHome.findByCategoryId(getCategoryId());
}catch(BusinessException e){
throw new SomeException(e.getMessage());
}
return col;
}
}
Then i have some definition code that initiates sets all the properties
(categoryId in the above example)
and then sends it off to the jsp to do its navigation.
There is also
<list:chunk iterator="wheretheiteratorisstashed" collectionTarget="items"
navigate="<%= navoption from request %>" >
<logic:iterate id="eachitem" name="items">
present the properties of eachitem
</logic:iterate>
<list:previous>something to display if there is a previous
(link)</list:previous>
<list:next>something to display if there is a next (link) </list:next>
</list:chunk>
Disclaimer:
I am not an architecht. Moreover, I am just out of college and still wet
behind the ears, but I would be glad to help
out with this. I would love to hear what you guys think.
Thanks a bunch in advance and keep up the great work.
Brian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Other possible tools for paging collections
Posted by Ted Husted <hu...@apache.org>.
"Craig R. McClanahan" wrote:
> I believe there is also an example app using this in the "contrib"
> directory of the HEAD branch of Struts, and therefore available in the
> nightly downloads.
Hasn't made it to contrib yet, but is available here
http://husted.com/struts/resources/struts-simple.zip
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Other possible tools for paging collections (another one)
Posted by Ed Hill <ed...@uiowa.edu>.
This thread has given me the boost from lurker to poster.
We have been working on something similar, and I would be willing to throw
our tag into the ring, or work with the original poster to see where there
is overlap, etc... (I don't know the design of the original, but the
features certainly seem very similar). You can see examples of our tag at:
http://edhill.its.uiowa.edu/taglib-gui/
We have been developing this tag for a little while, and are now finishing
up our last bit of functionality (data exporting to csv, excel, etc...), and
will start on the documentation next.
Like the original poster, my stuff is not quite ready for primetime, but I'm
willing to package up the source and make it available after Thanksgiving.
You should be able to get an idea of our design by looking around the
example pages (and yes, not everything works, etc...)
I was hoping to contrib to either struts or JSP taglibs. I wasn't sure
which was more appropriate. The design of the tag certainly follows some
struts conventions. If there is interest, let me know.
I'll post a follow up note, once I package up the source.
Thanks.
-Ed Hill (ed-hill@uiowa.edu)
Software Developer - Information Technology Services - University of Iowa
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Other possible tools for paging collections
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 15 Nov 2001, Brian Cochran wrote:
> Date: Thu, 15 Nov 2001 18:31:58 -0500
> From: Brian Cochran <br...@bricom.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Other possible tools for paging collections
>
> Writing paging (i.e. next, previous, etc) iterators can be a real pain to do
> correctly (at least it is for me).
No, not just for you ... it is a real pain, especially if you want to
generalize your design :-).
> Looking at the petstore, they seem to wuss out on doing it nice. It occured
> to me that there are a few options as far as doing iteration over pages.
>
> 1) retrieve all results and keep them in memory (in a session var i guess)
> while the user pages through them.
Works for small result sets, not large ones.
> 2) go to the db every time.
Ideally, you would keep track of where you are in a way that lets you
start "where you left off", so you don't have to skip all the rows that go
on previous pages.
>
> 3) JDBC 2.0 allows scrollable recordsets so you could have time-out-able
> recordsets that essentially close themselves
> on a time expiration and may reopen themselves if needed. (May be some
> nasty concurrency problems with this)
>
The biggest problem is that keeping the RowSet open means you are also
keeping the underlying Connection (instead of returning it to the pool),
so you end up needing *lots* more database connections for a given user
population.
> 4) create a hybrid that will cache some of the pages and go to the database
> if needed. Maybe be able to configure
> the number of pages to cache. Really cool would be able to change it
> dynamically.
>
> 5) somebody elses neat idea
>
An approach I've been dabbling with is in the "Workflow" project of the
jakarta-commons-sandbox CVS repository, and also available as a nightly
download:
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-workflow/
The basic idea is that you "script" the flow of processing for a
particular multi-page interaction with the user in an XML-format file,
which includes the ability to support paging. While my original focus was
on wizard-style interactions, it would be possible to use this as the
basis for a paging mechanism as well, but still be extensible.
I believe there is also an example app using this in the "contrib"
directory of the HEAD branch of Struts, and therefore available in the
nightly downloads.
Craig
>
> But whatever is used there is the basic principle of getEntities(int index,
> int span). So what do you guys think about
> a series of paging iterators that looked something like this.
>
> abstract class PagingIterator
> abstract List getEntities(int startIndex, int span)
> int getPage()
> void setPage(int page)
> boolean hasNextPage()
> void nextPage()
> boolean hasPreviousPage()
> void previousPage()
>
> class RequeryPagingIterator extends PagingIterator // like the petstore
> abstract List getEntities(int startIndex, int span)
>
>
> class CacheingPagingIterator extends PaginingIterator // good for a lot
> of smaller datasets
> List _AllEntities = null;
> List getEntities(int startIndex, int span){
> if(_AllEntities == null){
> getAllEntities();
> }
> int stopIndex = max(startIndex + span, _AllEntities.size() - 1);
> return _AllEntites.subList(startIndex, stopIndex);
>
> }
>
> class MultiplePageCachingPagingIterator extends PagingIterator // great
> little combination
> ...
>
> class ResultSetPagingIterator extends PagingIterator { // little new to
> JDBC 2 so not sure bout this (suggestions)
> ... // used with JDBC 2.0
> }
>
> The cool thing is the tags on the JSP's all work with PagingIterator so
> there is no need for the page to know how
> the paging is implemented.
>
> Some other things. Currently i have a messy implementation of this running
> inside struts. Works ok. but basically some
> of the challenges include
> 1) knowing when the query is new and when its navigation. currently I check
> for the presense of a navigate in
> the request params.
> 2) where and when to stash the iterator. Currently I'm stashing it in the
> session using some other custom tags.
> 3) should the getEntities thing be done as an interface instead of an
> abstract method? e.g
> new SomePagingIterator(ChunkableRetriever c) where ChunkableRetriever has
> a method getEntities(int start, int span)
>
> 3) how do you cleanly handle errors (I suck at error handeling in JSPs)
>
>
>
> Here's an example how its being used.
>
> ItemsByCategoryPagingIterator extends RequeryPagingIterator {
> String _CategoryId = null;
>
> Collection getEntities(int start, int span) throws SomeException {
> Collection col = null;
> try {
> col = itemsHome.findByCategoryId(getCategoryId());
> }catch(BusinessException e){
> throw new SomeException(e.getMessage());
> }
> return col;
> }
> }
>
> Then i have some definition code that initiates sets all the properties
> (categoryId in the above example)
> and then sends it off to the jsp to do its navigation.
>
> There is also
> <list:chunk iterator="wheretheiteratorisstashed" collectionTarget="items"
> navigate="<%= navoption from request %>" >
> <logic:iterate id="eachitem" name="items">
> present the properties of eachitem
> </logic:iterate>
> <list:previous>something to display if there is a previous
> (link)</list:previous>
> <list:next>something to display if there is a next (link) </list:next>
>
> </list:chunk>
>
> Disclaimer:
> I am not an architecht. Moreover, I am just out of college and still wet
> behind the ears, but I would be glad to help
> out with this. I would love to hear what you guys think.
>
>
> Thanks a bunch in advance and keep up the great work.
> Brian
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>