springframework-developer

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

[Rainer S. <Rai...@ab...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDocRPav/AIDHDd+YRAhV+AKCCRpmWEJQT9+fnFfC2Tx3kyfmTVQCgh4Go
ESCH2Dt+erVxUQqb5yfVbRg=
=T/uY
-----END PGP SIGNATURE-----

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

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

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

[Rainer S. <Rai...@ab...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Lewis wrote:

> 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?
Without having spend much time to think about it: we need the servlet
stuff anyway, so I don't see a problem referencing it where it's needed.


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

Meanwhile I think it's a bug in Liferay, too. The Portlet spec says in
section PLT.11.1.1:

  Commonly, portals provide controls to change the portlet mode and the
  window state of portlets. The URLs these controls use are generated by
  the portal. Client requests triggered by those URLs must be treated as
  render URLs and the existing render parameters must be preserved.

I've found an unresolved issue in the Liferay JIRA providing a simple
patch (LEP-478 if anyone is interested). I also asked a question at the
forums, I hope the bug will be fixed in the next Liferay release.
Anyway, no need to change the Portlet MVC behaviour.


> 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.
Sure. As you might have noticed I'm still struggling with porting my
application to Liferay ;-) But after things have stabelized I'm eager to
integrate the newest version of Portlet MVC.

Cheers,
Rainer

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: GnuPT 2.6.1.1 by EQUIPMENTE.DE
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDoqoGav/AIDHDd+YRAkhRAKCG/1tElC7mFi/oPZnsO1GFX/HbDgCgwS7B
Wf3OGfcsXoyfhmYrqgmYEyk=
=ZdKC
-----END PGP SIGNATURE-----