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
