Note that the "showForm" call happens in SimpleFormController's "renderFormSubmission" method, not in "processFormSubmission", due to the separate action/render phases in a Portlet environment. This does work in our test cases, so it doesn't seem that there's a general problem in SimpleFormController's workflow. Can you please double-check the behavior that you get, and post the relevant parts of your configuration?

Juergen

Hi Juergen,

First of all, thanks for your fast response to my issue.

You are correct, I did not notice the 'showForm' call in the 'renderFormSubmission' method. However, it turns out that the 'renderFormSubmission' method on my form controller is never called after submission of the form. Instead, the render phase (after the form submission action) is handled by my basic default controller that just forwards to the 'home' view.

After debugging, it seems that the flow is:

1. click on the link that goes to the 'registerUser' form
a. <portlet:renderURL><portlet:param name="action" value="registerUser" /></portlet:renderURL>
2. the 'handleRenderRequestInternal' method of my RegisterUserController is called, which results in the method 'showNewForm' being called
3. the form view is rendered in the portlet
4. fill in faulty data in the form (keep the fields blank) and submit it
5. the 'handleActionRequestInternal' method of the RegisterUserController is called, which results in form validation and the 'processFormSubmission' method being called
6. the 'processFormSubmission' method detects data binding errors and calls the 'passRenderParameters' method
7. the 'passRenderParameters' method returns immediately, because 'this.renderParameters' is null
8. my basic default SelfcareController is then called for the render phase
9. the 'home' view is rendered in the portlet

At step 7, the parameter 'action' with value 'registerUser' is not passed to the render request. This results in the default controller being invoked, instead of returning to the form view with errors. The javadoc description of the 'passRenderParameters' method is:

'Pass the specified list of action request parameters to the render phase by putting them into the action response object. This may not be called when... '

Can I conclude that the implementation of this method in the AbstractFormController is incorrect?

For completeness, I will attach my 'selfcare-portlet.xml' and 'applicationContext.xml' configurations.

Kind regards,
Jonathan

DispatcherPortlet configuration

Application context configuration

PS Please remove attachment #3 (selfcare-portlet.xml 06:13 AM)

Any progress on this issue?

Jonathan

"Pass the specified list of action request parameters to the render phase by putting them into the action response object."

You need to specify the list of parameters to pass to the next phase by setting the renderParameters property. See the setRenderParameters method in AbstractFormController, and also the exposed configuration properties section of the class level javadoc for details.

Hopefully, by specifying "action" as one of the parameters to be passed this will resolve your issue.

Thank you Chris, this does resolve the immediate problem.

In my opinion however, this should not be necessary. Without specifying the 'action' parameter, the form functionality does not work.

Both the Spring Portlet MVC reference and the wiki do not mention the 'renderParameters' property. Also, the Spring Portlet sample provided by the wiki does not use the 'renderParameters' property.

Shouldn't the 'action' parameter always be passed to the render phase, regardless of the 'renderParameters' property?

I am fairly new to the framework and at first I agreed with your comment. But when I thought about it, the only reason that the action parameter needs to be mapped is you have multiple controllers backing your portlet. So this is actually a handler mapping issue instead of a controller issue. The class org.springframework.web.portlet.handler.ParameterMappingInterceptor is probably the intended method of solving this issue when using multiple controllers in this fashion (or alternatively the solution I suggested above if redirects are required - the javadoc for the ParameterMappingInterceptor explains this). See http://static.springframework.org/spring/docs/2.0.x/reference/portlet.html#portlet-handlermapping for the explanation on use of different handler mappings. Section 16.5.6 explains the use of the ParameterMappingInterceptor to ensure that the same controller handles the action and render phases.

Hope this helps.

Chris.

BTW - the sample application available from http://opensource.atlassian.com/confluence/spring/display/JSR168/Home has a books example that uses this approach. The relevant section of the config to declare and use the ParameterMappingInterceptor is:

<bean id="parameterMappingInterceptor" class="org.springframework.web.portlet.handler.ParameterMappingInterceptor"/>

<bean id="portletModeParameterHandlerMapping" class="org.springframework.web.portlet.handler.PortletModeParameterHandlerMapping">
<property name="order" value="10"/>
<property name="interceptors">
<list>
<ref bean="parameterMappingInterceptor"/>
</list>
</property>
<property name="portletModeParameterMap">
<map>
<entry key="view">
<map>
<entry key="books"><ref bean="booksController"/></entry>
<entry key="addBook"><ref bean="bookAddController"/></entry>
</map>
</entry>
</map>
</property>
</bean>

Thank you Chris! That did the job.

As you might have guessed, I'm also new to the framework and I missed the importance of that section in the reference manual. For every portlet that uses more than 1 controller, this part of the configuration is absolutely vital to get the framework working (IMHO).

To help other (new) users of the Portlet MVC framework, I'd like to suggest to add another configuration example to (or after) section 16.5.6 that demonstrates the combined use of the portlet mode and portlet mode parameter handler mappings, together with the parameter mapping interceptor:

<bean id="parameterMappingInterceptor" class="org.springframework.web.portlet.handler.ParameterMappingInterceptor" />

<bean id="portletModeParameterHandlerMapping" class="org.springframework.web.portlet.handler.PortletModeParameterHandlerMapping">
<property name="order" value="10" />
<property name="interceptors">
<list>
<ref bean="parameterMappingInterceptor" />
</list>
</property>
<property name="portletModeParameterMap">
<map>
<entry key="view"><!-- 'view' portlet mode -->
<map>
<entry key="add" value-ref="addItemHandler" />
<entry key="edit" value-ref="editItemHandler" />
<entry key="delete" value-ref="deleteItemHandler" />
</map>
</entry>
<entry key="edit"><!-- 'edit' portlet mode -->
<map>
<entry key="prefs" value-ref="prefsHandler" />
<entry key="resetPrefs" value-ref="resetPrefsHandler" />
</map>
</entry>
</map>
</property>
</bean>

<bean id="portletModeHandlerMapping" class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
<property name="order" value="20" />
<property name="portletModeMap">
<map>
<entry key="view" value-ref="viewHandler" />
<entry key="edit" value-ref="editHandler" />
<entry key="help" value-ref="helpHandler" />
</map>
</property>
</bean>

I guess this issue can be closed. Thanks for your help!

By the way... I agree with you on it being a handler mapping issue instead of a controller issue

I think this "feature" is badly enough documented to be called a bug. The section 16.5.2 "ParameterHandlerMapping" should clearly point out the need for ParameterMappingInterceptor. Or, in order to be more intuitive: 1) the whole notion of one portlet -> multiple handlers should be discouraged and the specific steps needed to enable it well documented, or 2) calling passRenderParameters() should by default be called automatically, regardless of the outcome of the earlier processing stages.

Personally, I found it puzzling that processFormSubmission() doesn't call passRenderParameters() in the typical case (ie. no errors, not a form change request). Without digging into the issue, it seemed unintuitive that in some cases it's called and in some not. The behaviour is not obvious and should thus be reconsidered or at least much, much more clearly documented.