Jeromy Evans - Blue Sky Minds wrote:
Here's some options:
1. store your results in the http session. This takes no effort but
won't scale very well.
2. Look at the paging implementation provided by displaytag. The
default behaviour loads all data and pages through it for you.
http://displaytag.sourceforge.net/11/index.html
3. pass all the results to the client in one request. Use a javascript
widget to page through the results entirely on the client. This would
be great if its not too much data to download
4. if you're using an ORM framework like hibernate or toplink, enabling
an object cache or query cache may achieve the effect you desire without
having to write any custom code (WRT hitting the database once and then
not needing to access it again for each page)
Right now I am going the Session route to store the full resultset as
returned from the db service call. (They do use Hibernate, but I have no
access to it, so I look at it basically as a service call, and in this
case, it has been ordained that they will return ALL the results, and
the front end can deal with it.) I then specify the starting index of
the results array I want, it brings back X more to show on the screen.
It's passable for now, but I have extreme limitations with regards to
future functionality, (sorting for example).
Passing it all to the client probably isn't the best option, given the
possible size of the result set.
I have been looking at DisplayTag this week as well, but in regards to
Struts 2, wouldn't I still have to store this resultset on the server
side. Otherwise, how would the Display tags get access to this
information? Wouldn't I again run into a scaling issue (which hopefully
will not happen in this current description of the system use?. This
would also get me things like Sorting, exports to CSV or Excel that they
want, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
