struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Reumann <>
Subject Re: some best practices questions
Date Wed, 07 Jul 2004 02:58:11 GMT
Christina Siena wrote:

> I recently developed an application with a complex UI. One of the
> pages required querying the database based on user selection and
> re-displaying the page with the retrieved data and any previous
> existing user selections. Four different fields can trigger a db
> query resulting in page re-display and validations can also result in
> page re-display. Each time the page is re-displayed, the "state" of
> the page must be "remembered" from the last time it was displayed.
> (still with me so far?) Most of the data retrieved is list data
> displayed in single- or multi-select lists and populated using
> html:options collection and LabelValueBean. (for those of you reading
> this post who have developed similar code, you will know what I'm
> referring to).
> In the action, the retrieved data is placed in session scope to
> minimize db hits. I thought this was a good idea at the time. For
> some reason, placing data in session scope is frowned upon by some
> members of my team (even if improves performance). Anyways, what I
> need are some ideas of the best practices that fellow Struts users
> follow when a page requires querying the db and re-displaying the
> page with the retrieved data and previous selections if placing the
> data in session scope is not an option. How can I recall the
> previously retrieved data without requerying the db? Would it make
> sense to hide the data in the page? (i.e. either using hidden fields
> or hidden select lists or to generate a JavaScript array). What are
> the risks, if any, of hiding the data in the page? (i.e.
> performance).
> If anyone has developed similar pages, can you tell me if you decided
> for or against placing data in session scope and why?

Here's is my 2cents. Personally I'm not as anti-session as most people, 
and I think to use it or not use has to be taken on a case per case 
basis. If your queries to generate the lists are not going be cached in 
anyway by the backend and/or they are expensive queries to run, the 
Session can be a better place to temporarilly store this information as 
the user progresses through the 'flow' as you've described above. Sure 
the data each time might not be perfectly fresh, so if that is a 
requirement than you will need to query after each new selection is 
chosen. I'd opt for testing out performance making a new query each time 
to generate your lists for the drop downs and see how it behaves. (If 
your data in the database will never be altered by an external process 
you can really leverage something like iBATIS that will cache queries 
for you so everything is golden).

You are asking a two part question, though, and one thing I think that 
you 'might' be confusing is the use of the lists in Session versus the 
ActionForm in Session (retaining user's selections). From what you are 
describing I would DEFIINITELY keep your form bean in Session scope for 
this. This way any chosen parameters will be remembered as you are 
brought back to the page. This is a perfectly legit use of the Session 
and don't let anyone convince you in to using a bunch of hidden 
variables and storing your form bean in request scope each time. (To me 
that is so stupid, how much memory is a Form bean going to take up in 
Session scope weighed out agains the ugliness and maintenance of dealing 
with a bunch of hidden variables and making sure they are always set 
etc. USE the Session in this case for you form bean). You are basically 
describing in a sense a "wizard" where the user might be brought along 
to different pages to collect data in a form, only you are simply 
reusing the same form with different lists.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message