struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <m...@michaelmcgrady.com>
Subject Re: some best practices questions
Date Wed, 07 Jul 2004 03:59:58 GMT
Ever thought about creating a new scope managed by your own manager from 
application scope?  That is an approach I have been thinking of more and 
more as of late.

At 08:35 PM 7/6/2004, you wrote:
>I used hidden select lists to restore user selections since I wasn't 
>"allowed" to place the whole form in session scope. The 
>management/maintenance of user selections was indeed ugly (but its done 
>and works fine). My question has to do with the data retrieved from the db 
>(from which the user makes selections). For example, when the form is 
>initially displayed, I populate a list of vehicle lines (i.e. Focus, 
>Mustang, Freestar, and so on). The user can copy a vehicle line from the 
>source list to the target list. The target list consists of user 
>selections. When the page needs to be re-displayed as a result of some 
>other query, I needed to re-populate the list of vehicle lines (the source 
>list). I felt that re-retrieving the same vehicle lines from the db again 
>was silly (since I got it once I simply put a map in session and use it 
>when needed). When posting the form, the list of label value beans is no 
>longer available in the action, so my options were: (1) either store in 
>hidden lists (concatenating the key with the description) or (2) 
>re-retrieve the vehicle lines from the db or (3) place them in session the 
>first they are retrieved and get them from session scope. I chose the 
>third and wondered about some best practices others have used in similar 
>situations.
>   ----- Original Message -----
>   From: Rick Reumann
>   To: Struts Users Mailing List
>   Sent: Tuesday, July 06, 2004 10:58 PM
>   Subject: Re: some best practices questions
>
>
>   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.
>
>   --
>   Rick
>
>   ---------------------------------------------------------------------
>   To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>   For additional commands, e-mail: user-help@struts.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message