>The *temporarily* saving of the StrutsRenderContext in the session
serves only 2 purposes (and has no relation or dependency on caching
whatsoever):

>a)
>An input validation error occurred requiring sending the current form
parameters back to the user and presenting some kind of error
message(s).
>This is similar in what Struts does in a native web context.
>If the user refreshes the returned page though, the form will be
cleared again. That is usually not the same as a native Struts web app,
but then, you won't get 
>that annoying "Post" warning from the browser either :)
>I myself find this "clear" error state on refresh quite user friendly
actually, but others might disagree.

>b)
>A processAction did result in a (jsp) forward, not redirect to a View
Action as should be done in a Portlet context.
>Although this is the result of an incorrectly configured Struts
*Portlet* application, the bridge tries to "solve" this as best as it
can by storing the current 
>state in the session. But as this is a "misuse" which should be fixed
(check your log files, you'll find this logged as a warning), the bridge
will keep this 
>saved state no longer than for 1 single request.

>Please (re)read my explanation why this is required at:
>
http://portals.apache.org/bridges/multiproject/portals-bridges-struts/fe
atures.html#Handling_ActionRequests

I think I have missed something indeed.
by "the Struts application too really should be configured to use
separate Action processing and View rendering Actions" 
do you mean that I should replace all forwards to a JSP in my mappings
with a forward to an action that forwards to a jsp like this :
<action path="/fooAction.do" ...>
    <forward name="success" path="/fooView.jsp"/>
</action> 
should be replaced with 
<action path="/fooAction.do" ...>
    <forward name="success" path="/fooView.do"/>
</action> 
 
<action path="/fooView.do" forward="/fooView.jsp"/>
 
 
 

Reply via email to