Cocula Remi wrote:
Re-Post : I previously posted this question in the user mailing list but had no response. I think this is an important question that concern developpers, so I try
to ask it again in this list.
As written in the StrutsBridge documentation : "The StrutsRenderContext is restored only once". Actually, the StrutsPortletRenderContext is removed from the session just after it's first retoration in the PortletServlet.performActionRenderRequest. I don't understand why.
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/features.html#Handling_ActionRequests

Regards,

Ate

The renderContext is restored during the RenderRequest that immediately follows an ActionRequest so the Struts processor cas get the path of the jsp it must forward to (see
PortletServlet.performActionRenderRequest).
But after that another renderRequest (without any ActionRequest) can be sent by the portal, for exemple if another portlet is activated. In this case, the RenderRequest can not be processed because the
renderContext is no more present in session.
That only works if the portal uses cache to render the portlet again but
it's not always the case (as I can notice on Liferay).
So why is the renderContext restored only once ? is it because we must
consider that the portal uses cache ?
And what would be the disadvantage of keeping the render context until a
new ActionRequest is processed ?

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to