Announcement Announcement Module
Collapse
No announcement yet.
Problem with portlet support... Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem with portlet support...

    User attribute are retreived in portlets by the following command:

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

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

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

    Comment


    • #3
      Seems unintuitive....

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

      Comment


      • #4
        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:

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

        Comment


        • #5
          Wouldn't it be more intuitive to check req for instanceof

          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)

          Comment


          • #6
            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

            Comment


            • #7
              Ok... I see what you mean...

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

              Comment


              • #8
                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

                Comment


                • #9
                  Here is clarification....

                  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

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      That is some progress but there may be a problem...

                      That is some progress but there may be a problem... If user doesn't request USER_INFO then on every portlet request the user will be taking the performance hit (if any) on retreiving the info. That could be significant or not dependent on caching.

                      I think you understand what the possibilities are though so I think if we continue along the path we may come up with something.

                      I will forward your latest suggestion to jetspeed people and see what they think wrt performance..

                      Comment

                      Working...
                      X