Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Maintaining lists of beans in a page

 
Rick Strahl
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I am using struts and I display to a page a list of information that basically consits of an id, some other information, and a check box. This information is populated in an action class and displayed on the screen. What I have to do is if a user checks a series of checkboxes and hits a submit button, information associated with that record has to be changed. The problem is I lose the lists of beans on the page when I want to do the submit. Does anyone know of a way to persist the list of beans without using a session variable, cause the list could be huge.

thanks,
Rick
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65535
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"rick S",

We're pleased to have you here with us on the Ranch, but there are a few rules that need to be followed, and one is that proper names are required. Please take a look at the JavaRanch Naming Policy and adjust your display name to match it.

In particular, your display name must be a first and a last name separated by a space character, and must not be obviously fictitious.

Thanks!
bear
Forum Bartender
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65535
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
a way to persist the list of beans


That's what the session is for.

If you already have them in memory, creating a reference to them in the session will not create any greater of a memory burden except for the miniscule amount needed to maintain the reference.

Just be sure to remove the session reference when you're done with them.

The other alternative is to put them into the page's form as hidden variables.
[ January 05, 2005: Message edited by: Bear Bibeault ]
 
Rick Strahl
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So I would assume the syntax for something like that would be
<html:hidden name="beanName" property="propertyName"/>

But because you are displaying a list of those, there are going to be many of those exact same lines. For instance,

<html:hidden name="studentBean" property="studentName"/>
//some code for the checkbox.
will be row one,
<html:hidden name="studentBean" property="studentName"/>
//some code for the checkbox.
will be row two, and so on.
Wouldent this cause a conflict? How would I send only some of these rows back to the server for processing. Say, only the ones that have had their checkbox checked?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65535
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The hidden value mechanism was mentioned only as an alternative -- one that would be complex and painful.

What's your beef with using the session?
 
Rick Strahl
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even though usually you would break up large lists into multiple smaller ones, and let the user cycle through different pages of lists, for right now, we are grouping them all in one call. So, there could be thousands of rows of information as well a decent amount of users of the system. As I presume, once the user makes their decisions regarding the checkbox and submits the information, thats when I would read back the information, process it and then delete all the information from session. But if it takes a user awhile to make that decision, you could have quite a few very large lists sitting in memory on the server.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65535
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, not an invalid concern. But before acting upon it, I think that there are two questions you need to ask yourself:

1) Am I the victim of premature optimization?

Are you just speculating that there might be a problem? If so, I'd go ahead and code it up and, during testing, determine if there really is a problem to be solved.

2) Am I taking too big a bite to begin with?

How much of this large dataset are you showing to the user? All of it? If so, you may be showing too much. Most UI studies will tell you that overloading the user with data is a common mistake. In this case, you should consider either paging your data, or giving your user better data filtering capabilities. Smaller data sets are better for the user and solve your problem.

If you can definitively answer "no" to both questions, then the search for a solution begins. Basically your problem is that you desire to not use in-memory persistence. Whether you do this in the session or not is moot. Any in-memory persistence mechanism will have the same drawbacks you are trying to avoid.

Some off the top of my head ideas (in order of my personal preference). All involve tacking some data onto the form as hidden elements:

1) Tack enough info onto the form in hidden variables to be able to recreate the data set from scratch during the next request.

2) Persist the data to disk or database and tack info to reclaim it on the form.

3) Dump the data itself into the form in hidden inputs. This is the least desirable since it'll make your page huge and you'll need to implement serialization to and from the flat request parameter namespace.

If you do decide that (3) is your answer, let me know; I have had to deal with this type of thing before. But I'd recommend eliminating everything else (with a very good reason) before resorting to that.
[ January 06, 2005: Message edited by: Bear Bibeault ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!