forwarding vs redirecting issue

[Chris Cheshire <ch...@gmail.com>]

Hi,

I have a design issue based around form submission, protecting against
resubmission etc.

I have seen a couple of design "guidelines" that seem to conflict.

1) Use the session as little as possible (memory issues etc)
2) Use forwards where possible as requests can be passed along, with
original information preserved, as well as speeding up communication.

Now the only problem I face is after an action is complete, if I
forward to a JSP, that action is open to resubmission when the user
starts playing with the reload and back buttons on their browser.
Redirects, because of the URL changing, can help protect against this.

So the solution seems to be to place the beans required by the JSP
page in displaying the result of the action in the session instead. So
now there is an issue of when do the objects for the action that was
just performed get removed from the session?

Do I just put something in the start of each action to remove from the
session all objects not associated with that action?

Thanks

Chris

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

Re: forwarding vs redirecting issue

[Ted Husted <te...@gmail.com>]

On 3/27/06, Michael Jouravlev <jm...@gmail.com> wrote:
> Session-scoped data allows you to navigate to any action keeping
> application state, so you don't need to obey an artificial page flow.
> I think this is a benefit usage-wise.
>
> I prefer to use session-scoped ActionForms and to put everything
> related to an object into the form as nested properties. This seems
> easier to handle for me.

As Michael says, there are significant benefits to using session
scope. In fact, the existance of session scope is one reason many
people chose Java in the first place. I still remember back in 2000
seeing many PHP frameworks struggling to create session scope that was
already built into Java.

Of course, you do need enough resources to support session scope for
all your users. And many of do have plenty of resources, so that is
not a problem. In fact, I know some very large business-to-consumer
sites that use session extensively, and successfully, to avoid
roundtrips to a database that might be on another continent.

The trick being that you need to load-test your application in your
environment to see if it meets your requirements :)

A useful technique, that came up on on aother thread recently, is to
create your own session object with the session, and store everything
you need there. This is what Michael is doing with ActionForms. In
"Programming Jakarta Struts", Chuck Cavenese implements a
"UserContainer" object to do the same sort of thing, and an
"ApplicationContainer" to manage whatever an application needs to
retain in global scope.

Sessions scope is a useful tool. The trick is not to scatter your
objects all around (like we do with the Action API), but to keep
everything in one place.

HTH, Ted.

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

Re: forwarding vs redirecting issue

[Madhav Bhargava <un...@gmail.com>]

another approach to handle session scoped objects is to create a filter that
will be responsible to clean up any session scope objects when they are not
needed. Alternatively you can also overwrite the RequestProcessor
processPreprocess method and do session cleaning there as well.

If you want struts to clean it for you then as stated above u can for
session scoped form beans.

--Madhav


On 3/27/06, Michael Jouravlev <jm...@gmail.com> wrote:
>
> On 3/27/06, Chris Cheshire <ch...@gmail.com> wrote:
> > Hi,
> >
> > I have a design issue based around form submission, protecting against
> > resubmission etc.
> >
> > I have seen a couple of design "guidelines" that seem to conflict.
> >
> > 1) Use the session as little as possible (memory issues etc)
> > 2) Use forwards where possible as requests can be passed along, with
> > original information preserved, as well as speeding up communication.
> >
> > Now the only problem I face is after an action is complete, if I
> > forward to a JSP, that action is open to resubmission when the user
> > starts playing with the reload and back buttons on their browser.
> > Redirects, because of the URL changing, can help protect against this.
> >
> > So the solution seems to be to place the beans required by the JSP
> > page in displaying the result of the action in the session instead. So
> > now there is an issue of when do the objects for the action that was
> > just performed get removed from the session?
> >
> > Do I just put something in the start of each action to remove from the
> > session all objects not associated with that action?
>
> I observe the common Struts pattern to "front" JSP pages with actions.
> I have a setup/render action that selects an appropriate JSP and
> forwards to it. I also have a submit action that handles the input.
> After submit action finished with input, it redirects to render
> action. So, I redirect from submit action to render action, but I
> forward from render action to a JSP page.
>
> You don't have to change URL in the address bar for redirect. Say, you
> have "showItem.do?id=1234" action that forwards to JSP and shows item
> form. You update item and submit it to "updateItem.do" action. It
> updates the database or if errors found, it generates errors, sticks
> them into session and redirects to "showItem.do?id=1234". Now you have
> the same URL in the browser again, with error messages in the form.
> Struts 1.2.6+ removes messages from session automatically after they
> were shown, but for anything else it is on you.
>
> Yes, controlling what is in session is a burden, and especially
> problematic if you allow a user to open several windows for one
> object. Then you cannot remove the object when the user returns to,
> say, a list of objects.
>
> This is a compromize. If you care about cleaner URLs and better user
> experience, use redirect and clean session yourself. Otherwise use
> Token object to prevent resubmits, but a user will still see POSTDATA
> message.
>
> Session-scoped data allows you to navigate to any action keeping
> application state, so you don't need to obey an artificial page flow.
> I think this is a benefit usage-wise.
>
> I prefer to use session-scoped ActionForms and to put everything
> related to an object into the form as nested properties. This seems
> easier to handle for me.
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


--
When I tell the truth, it is not for the sake of convincing those who do not
know it, but for the sake of defending those that do

Re: forwarding vs redirecting issue

[Michael Jouravlev <jm...@gmail.com>]

On 3/27/06, Chris Cheshire <ch...@gmail.com> wrote:
> Hi,
>
> I have a design issue based around form submission, protecting against
> resubmission etc.
>
> I have seen a couple of design "guidelines" that seem to conflict.
>
> 1) Use the session as little as possible (memory issues etc)
> 2) Use forwards where possible as requests can be passed along, with
> original information preserved, as well as speeding up communication.
>
> Now the only problem I face is after an action is complete, if I
> forward to a JSP, that action is open to resubmission when the user
> starts playing with the reload and back buttons on their browser.
> Redirects, because of the URL changing, can help protect against this.
>
> So the solution seems to be to place the beans required by the JSP
> page in displaying the result of the action in the session instead. So
> now there is an issue of when do the objects for the action that was
> just performed get removed from the session?
>
> Do I just put something in the start of each action to remove from the
> session all objects not associated with that action?

I observe the common Struts pattern to "front" JSP pages with actions.
I have a setup/render action that selects an appropriate JSP and
forwards to it. I also have a submit action that handles the input.
After submit action finished with input, it redirects to render
action. So, I redirect from submit action to render action, but I
forward from render action to a JSP page.

You don't have to change URL in the address bar for redirect. Say, you
have "showItem.do?id=1234" action that forwards to JSP and shows item
form. You update item and submit it to "updateItem.do" action. It
updates the database or if errors found, it generates errors, sticks
them into session and redirects to "showItem.do?id=1234". Now you have
the same URL in the browser again, with error messages in the form.
Struts 1.2.6+ removes messages from session automatically after they
were shown, but for anything else it is on you.

Yes, controlling what is in session is a burden, and especially
problematic if you allow a user to open several windows for one
object. Then you cannot remove the object when the user returns to,
say, a list of objects.

This is a compromize. If you care about cleaner URLs and better user
experience, use redirect and clean session yourself. Otherwise use
Token object to prevent resubmits, but a user will still see POSTDATA
message.

Session-scoped data allows you to navigate to any action keeping
application state, so you don't need to obey an artificial page flow.
I think this is a benefit usage-wise.

I prefer to use session-scoped ActionForms and to put everything
related to an object into the form as nested properties. This seems
easier to handle for me.

Michael.

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