PortletMVC - RenderCommand Usage?

I've recently been using Spring Portlet MVC on a demonstrator application using Weblogic Portal Server 8.1 and ran into something interesting. Not sure if this is an issue, or just how things are.

The issue I've run into is when switching from Edit to View modes, after a form submission in the Edit mode. My edit and view modes have two different command objects, and it would seem that the last one that I've done a form submission on is having its command object cached as the 'RenderCommand'. This causes the view (JSP with JSTL) to barf, since it can't find its command object due to how the render request is handled. (formBackingObject isn't called) I've managed to get around this by overriding the onSubmitRender() methods on both controllers. (by explicitly calling formBackingObject() myself)

My question is: Is this how its supposed to act?

Seems kind of odd, since I'd expect the RenderCommand to be the Command object for the controller. But perhaps I'm just ignorant to the difference between the Command and RenderCommand objects. Anyone have any insight?

(New to the whole Portal thing, and Weblogic Portal is not helping much with my education on JSR-168 based portlets...)

Sorry for the slow reponse -- I have been remiss in responding to forum questions.

This is one of the most annoying side-effects of the JSR-168 spec making it almost impossible to communicate effectively between the action phase and the render phase of the request.

The reason this is happening is because one of your AbstractFormController based classes will set a render Parameter to indicate that the form was submitted. Then when you change mode, the render parameters are preserved, but you are mapped to a different Controller that is still fed that same render parameter and thinks a form was just submitted.

The workaround for this is to override the 'getFormSubmitParameterName' method in your EDIT mode controller to use a different parameter name from the Controllers that are in your VIEW mode.