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

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

Oh, the other thing that changes is that ViewRendererServlet moved from 
the .portlet package to the .servlet package -- that will need to be 
changed in your web.xml file.  That would also cause you to not be able 
to render anything... ;)

John Lewis wrote:

> 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
>>
>>  
>>
>