Problem with portlet support...

[garpinc2]

User attribute are retreived in portlets by the following command:

Map userInfo = (Map)request.getAttribute(PortletRequest.USER_INFO);

Because webflow copies the request attributes into the request rather than using the PortletRequest directly there is a problem (at least with jetspeed2)

The problem is that when above command is executed it executes special code. There is no actual request attribute in the request.

So a workaround needs to be found for this.

perhaps a method on requestContext that will determine if the actual request is a portlet and call the getAttribute on that instead. Maybe there it a completely better way of course...

I created JIRA

http://opensource.atlassian.com/proj...rowse/SPR-1030

[klr8]

You can do this by getting the actual PortletRequest in your action:

RequestContext context = ...
PortletRequest request = ((PortletEvent)context.getSourceEvent()).getRequest();
Map userInfo = (Map)request.getAttribute(PortletRequest.USER_INFO);

If you want to keep your action code independent of the Portlet API, you could do something similar in a FlowExecutionListener.

Erwin

[garpinc2]

Seems unintuitive.... since every other request param is done in a different way however please provide an example on how to do this with FlowExecutionListener and describe how it keeps this stuff separate from my code..

[klr8]

Doing it in a listener makes it more pluggable. If you want to reuse your flow in a servlet and portlet environment, you can plug in the correct listener in each case and the flow itself remains protocol independent.

A listener could e.g. do it in the "requestSubmitted" hook:

public void requestSubmitted(RequestContext context) {
   if (!context.getFlowContext().isActive()) return;
   PortletRequest request = ((PortletEvent)context.getSourceEvent()).getRequest(); 
   Map userInfo = (Map)request.getAttribute(PortletRequest.USER_INFO); 
   context.getFlowScope().setAttribute("userInfo", userInfo);
}

Erwin

[garpinc2]

Wouldn't it be more intuitive to check req for instanceof in the case of that attribute and do that automatically since in general that is how that attribute will be used?

I don't see how listener accomplishes anything interesting since I could do the same by chaining together actions... It still means however that my code is portlet specific which is the general idea of what this framework was trying to avoid (and I might add, has done a good job so far)

[klr8]

The main benefit of the listener is pluggability. E.g. you could take it out and reuse the flow in a servlet situation without any changes to the actual flow definition and actions.

Erwin

[garpinc2]

Ok... I see what you mean... however I still think it's unintuitive and the jetspeed2 guys also think so but if you want to go this way I guess we'll have to live with it. :-(

Otherwise you guys are doing great work so hopefully we can agree on this point to disagree.. :-)

[klr8]

I'm not following.

What exactly are you suggesting?

Wouldn't it be more intuitive to check req for instanceof in the case of that attribute and do that automatically since in general that is how that attribute will be used?

Could you clarify that a bit?

Erwin

[garpinc2]

In requestContext instead of going to map to retrive an attribute of

PortletRequest.USER_INFO if context.getSourceEvent() is instanceof
PortletEvent then execute the following command to retreive value

PortletRequest request = ((PortletEvent)context.getSourceEvent()).getReques t();
Map userInfo = (Map)request.getAttribute(PortletRequest.USER_INFO );


I don't understand why the copy to the map was done in the first place why couldn't you do the same kind of thing for servlets as well

[klr8]

Maybe I'm just thick, but I'm still not getting what you're suggesting. Are you suggesting putting some code in RequestContext.getAttribute() that checks if the source event is a PortletEvent and if the request parameter is "USER_INFO" that it then pulls that info from the PortletRequest? If so, that's not possible since the RequestContext is completely protocol independent, and should remain that way.

I guess an alternative would be to do it in the PortletEvent itself, when it extracts all parameters from the PortletRequest.

Erwin