[Springframework-developer] Re: Portlet MVC in Spring 2.0-m1

[John L. <jl...@ar...>]

Rainer!  Good to hear from you.

I think the portlet MVC code that is in 2.0-M1 got pulled out of the 
sandbox image.  The portlet code in the sandbox is currently not functional.

Juergen has made an extensive pass through the code and has provided a 
number of improvements.  One is the elimination of references to the 
org.springframework.web.servlet classes throughout the 
org.springframework.web.portlet API.  This required a new ModelAndView 
class and a few other key changes.  This along with some changes to the 
way the ApplicationContext works in portlets has made things much cleaner.

The current problem with the portlet code in the sandbox is that we have 
eliminated the LocaleResolver (since the portal is responsible for 
locale management) but there are appear to be some View 
rendering-related classes that are looking for it instead of using the 
LocaleContextHolder.  I am working on straightening out these issues 
right now and the sandbox code should be functional again soon.

One concern I have about the new ModelAndView class is that it does not 
currently allow the View object to be created directly -- it can only be 
set by name and must then be loaded by a ViewResolver.  Adding in the 
methods for setting the View directly would result in one set of API 
methods that reference the servlet-side classes, but given that we use 
the servlet-side infrastructure to do all the rendering I think this 
might be reasonable.  What are your thoughts on this?

As for the Liferay issue, this sounds like a bug in Liferay.  The 
default behavior of handleActionRequestInternal and 
handleRenderRequestInternal in AbstractController (i.e. throwing 
Exceptions) is modeled after the default behavior of processAction, 
doView, doEdit, and doHelp in the GenericPortlet from the JSR-168 API.  
In fact, this behavior was requested by a number of users in order to be 
consistent with the API.  I think it would be better to get Liferay to 
fix their bug than to try to work around it in the Spring framework.  As 
I think about, this is actually a pretty serious bug in Liferay.  What 
if you have a bunch of legitimate database manipulation code in your 
handleActionRequestInternal?  Will it try to run that every time you 
change the window state?  That doesn't sound good.  Let me know what you 
think.

I should have a new build of the portlet framework out soon that is 
based on the sandbox code.  I'll appreciate your help in testing this.

Thanks,
John




Rainer Schmitz wrote:

>Aloha!
>
>Is the Portlet MVC in 2.0-M1
>(spring-framework-2.0-m1-with-dependencies-build.383-20051214.zip)
>supposed to work?
>My portlet application works with Portlet MVC as published in the
>confluence wiki. But after switching to 2.0-M1 the portlet content is
>not rendered anymore. There are no error messages, and the controllers
>are processed correctly. Deploying the portlet sample application showed
>the same effect (uisng Liferay 3.6.1).
>
>BTW: I had to change my portlets to use
>org.springframework.web.portlet.ModelAndView instead of
>org.springframework.web.servlet.ModelAndView. What's the reason for the
>new ModelAndView class?
>
>Another issue is related to Liferay. It seems Liferay is creating Action
>Requests to change the portlet window state. This means a portlet will
>receive action requests even if it is not meant to handle these
>explicitely.
>The problem is that the default implementation of
>handleRenderRequestInternal(ActionRequest, ActionResponse) in
>AbstractController throws an Exception. To work in Liferay every
>controller has to overload this method (same for render requests).
>I propose to change the methods in AbstractController to just do nothing
>(or maybe to issue a debug or warning message).
>
>Rainer
>
>  
>