I have an idea how to persist the data that I currently place in session scope but I
need to run it by someone.
Recall when I said that placing data in session scope is frowned upon by some members
of my team? Well no one said anything about not using Java serialization. Why couldn't
I serialize the
same data that I currently keep in session scope? I've already implemented a solution
for streaming images so creating a temp file should not be a problem. Here is what I
think I will need:
In the action where the data is first retrieved:
try {
final String prefix = "myVehicleLineMap";
final String suffix = null;
File file = File.createTempFile(prefix, suffix);
FileOutputStream fileOutputStream = new FileOutputStream(file);
ObjectOutputStream objectOutputStream = new ObjectOutputStream(fileOutputStream);
objectOutputStream.writeObject(myMap);
objectOutputStream.flush();
myForm.setTempFileName(file.getAbsolutePath());
} catch (Exception e) {
System.out.println(this.getClass().getName() + "==>> " + e.toString());
}
In the action where the data needs to be re-accessed to prepare the page for
re-display:
try {
FileInputStream fileInputStream = new FileInputStream(myForm.getTempFileName());
ObjectInputStream objectInputStream = new ObjectInputStream(fileInputStream);
SortedMap myMap = (SortedMap) objectInputStream.readObject();
// use myMap as before (when in session scope)
} catch (Exception e) {
System.out.println(this.getClass().getName() + "==>> " + e.toString());
}
This is just an idea at this point, so I would welcome any feedback. I'm not sure if
this will work or if its feasible, but at least it may generate some more ideas.
----- Original Message -----
From: Michael McGrady
To: Struts Users Mailing List
Sent: Tuesday, July 06, 2004 11:59 PM
Subject: Re: some best practices questions
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
