struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <>
Subject RE: Multiple forms in session [WAS: RE: how to send actionForm from one action to another action]
Date Wed, 18 Dec 2002 03:23:56 GMT
In my application we have a need for multiwotsit editing.

As it happens this potential trampling isnt an issue for me as I already
developed a(n evil) method for handling this sort of thing earlier (in
response to other requirements I had). Its not a technique Id recomend as a
general solution , although it works well in the particular application I am
working on.

I have an class I named the "OperationContext". Instances of
OperationContext are at heart a HashMap into which attributes can be put.
This is itself stored in the session context under a unique key. (This key
obviously has to be submitted with any request related to this
OperationContext so that it can be found again). Ive overridden the
RequestProcessor to look for my actionForms in the OperationContext first
(if there isn't an opcon or the form is request scope it just uses normal
handling). Opening a wotsit page to edit a wotsit will cause a new
OperationContext to be created. Saving the wotsit finishes the operation and
the opcon is removed.

There are several issues to consider with this sort of thing of course (many
of which are generic to anything you store in session context). Ie: The
overhead involved in making sure that the opcon id is submitted with
request, how to know when to get rid of the opcons - no problem if the user
goes through the whole editing cycle, but they can always abandon an
Operation halfway to go do something else. Theres also the issue of server
memory usage for all the stuff in the session. Not a problem in my app, but
if I was rewriting I reckon Id be looking for a different

-----Original Message-----
From: Eddie Bush []
Sent: Wednesday, December 18, 2002 12:11
To: Struts Users Mailing List
Subject: Re: Multiple forms in session [WAS: RE: how to send actionForm
from one action to another action]

Andrew Hill wrote:

>One thing Ive never understood about forms in session scope, is how does
>struts deal with the situation where there are two concurrent requests in
>the same session both of which are for the same action (and form type)?
They would use the same form, I'd think.  If you needed multiple
different copies you'd have to literally have different forms :-(

>As far as I can make out however, the key for a form is fixed without a way
>to differentiate different instances of the same form type. Is this
>the case or havent I read the code closely enough?
I haven't noticed it if it's there either.  I was just looking at places
where forms are created and placed into scope because of this thread.
 It's all quite straight-forward.  You could easily trample on your form
if you're not careful.  Yet another reason to use request scoped forms.

>You have a page: editWotsits.jsp that uses the WotsitActionForm and submits
>to WotsitAction. The requirement is that the wotsit pages open in new
>windows (ie: <a target="_new"...) or frames, such that the user can be in
>the process of editing multiple wotsits at any given time. Due to some
>requirements (fancy workflow perhaps?) the request scope isnt an option and
>these WotsitActionForms all need to be in session scope.
They'd get trampled :-(  In fact, there's really not a good solution
that comes to mind.  The only single thing I see that we can do to make
using session-based forms more safe is to add the module name to the key
we use to place the forms into scope.  I'm going to go look for that bug
now - nearly certain it's there.

>-----Original Message-----
>From: Eddie Bush []
>Sent: Wednesday, December 18, 2002 11:34
>To: Struts Users Mailing List
>Subject: Re: how to send actionForm from one action to another action
>It's actually a combination of the module name and the form name.  Now
>that we have modules, a strategy has to be used which allows each module
>to have forms of the same name.  The source code would definitely be the
>place to see exactly how the name is arrived at - I'd tell you, but I
>haven't looked at it since it was updated.
Eddie Bush

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

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

View raw message