Portlet mode change via WSRP

[Kevin Irmscher <ke...@gmail.com>]

Hi!

I'm still implementing portlets in order to test WSRP functionality.
I tried to accomplish a simple functionality of a mode change of a
portlet. It works if it's done like this for example in a JSP:

<%
        PortletURL url = renderResponse.createRenderURL();
	url.setPortletMode(PortletMode.HELP);
%>
<a href="<%=url.toString()%>">Change to Help Mode</a>

However, my first approach was this one:
JSP code:
<a href="<portlet:actionURL>
		<portlet:param name="mode" value="help"/>
     	     </portlet:actionURL>">Change
</a>

Portlet code:
public void processAction(ActionRequest request,
			ActionResponse actionResponse) throws PortletException, IOException {
   String mode = request.getParameter("mode");
   if (mode.equals("help")) {
	response.setPortletMode(PortletMode.HELP);
   }
}

The latter works with a locally deployed portlet. Consuming a portlet
from a WSRP4J producer, the state change will only be performed in the
first solution.
The first one works because the consumer invokes getMarkup() with the
portlet mode HELP as markup parameter. The producer's response is
according to this parameter.

In the second approach, the consumer invokes
performBlockingInteraction() and the portlet mode is set on the
producer side in the processAction method. The producer's
performBlockingInteractionResponse does not contain the newMode tag.
That's why the consumer calls getMarkup() with portlet mode VIEW as
markup parameter. The producer complies to this request and sends the
markup of the view mode.

Maybe I'm wrong but I think this is a problem of the WSRP4J producer.
If it sent newMode=help in its response, the consumer would react on
that and set the correct parameter in the subsequent getMarkup
request.

Any opinions on that issue?

Regards,
Kevin

Re: Portlet mode change via WSRP

[Diego Louzán <dl...@apache.org>]

Kevin Irmscher escribió:
> Hi!
> 
> I'm still implementing portlets in order to test WSRP functionality.
> I tried to accomplish a simple functionality of a mode change of a
> portlet. It works if it's done like this for example in a JSP:
> 
> <%
>        PortletURL url = renderResponse.createRenderURL();
>     url.setPortletMode(PortletMode.HELP);
> %>
> <a href="<%=url.toString()%>">Change to Help Mode</a>
> 
> However, my first approach was this one:
> JSP code:
> <a href="<portlet:actionURL>
>         <portlet:param name="mode" value="help"/>
>              </portlet:actionURL>">Change
> </a>
> 
> Portlet code:
> public void processAction(ActionRequest request,
>             ActionResponse actionResponse) throws PortletException, 
> IOException {
>   String mode = request.getParameter("mode");
>   if (mode.equals("help")) {
>     response.setPortletMode(PortletMode.HELP);
>   }
> }
> 
> The latter works with a locally deployed portlet. Consuming a portlet
> from a WSRP4J producer, the state change will only be performed in the
> first solution.
> The first one works because the consumer invokes getMarkup() with the
> portlet mode HELP as markup parameter. The producer's response is
> according to this parameter.
> 
> In the second approach, the consumer invokes
> performBlockingInteraction() and the portlet mode is set on the
> producer side in the processAction method. The producer's
> performBlockingInteractionResponse does not contain the newMode tag.
> That's why the consumer calls getMarkup() with portlet mode VIEW as
> markup parameter. The producer complies to this request and sends the
> markup of the view mode.
> 
> Maybe I'm wrong but I think this is a problem of the WSRP4J producer.
> If it sent newMode=help in its response, the consumer would react on
> that and set the correct parameter in the subsequent getMarkup
> request.
> 
> Any opinions on that issue?
> 
> Regards,
> Kevin

Yes, IIRC the WSRP specification states that mode/state changes in 
performBlocking have to been honoured on subsequent getMarkup requests, 
so it seems a producer error. I'll try to check it soon.

Regards.
Diego.