struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <ravi.ved...@wipro.com>
Subject RE: some best practices questions
Date Thu, 08 Jul 2004 05:08:41 GMT
I think, performance wise File I/O is not the right idea. 

What do you say ?

-----Original Message-----
From: Christina Siena [mailto:csiena@mountaincable.net] 
Sent: Thursday, July 08, 2004 8:16 AM
To: Struts Users Mailing List
Subject: Re: some best practices questions

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: 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


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


Mime
View raw message