portletspec3
  1. portletspec3
  2. PORTLETSPEC3-27

Errata: PortletMode and WindowState request during resource serving wit FULL cacheability

    Details

      Description

      During a resource serving with cacheability FULL a portlet cannot access the window state and portlet mode (neither the render parameters).

      The specification says is vague and say: "Thus the portlet should not access the portlet mode, window state, or render parameters in the serveResource call."

      The current Javadoc does not specify anything particular , for example PortletRequest#getPortletMode() say "Returns the current portlet mode of the portlet" .

      I think we lack of clarity as we don't specify what PortletRequest#getPortletMode() and PortletRequest#getWindowState() should return in this case.

      I believe it should return null and we should say it clearly in the Javadoc, for example we could redeclare those methods in the ResourceRequest interface and add to the javadoc that in case of FULL cacheability then null is returned.

        Activity

        julien_viet created issue -
        julien_viet made changes -
        Field Original Value New Value
        Summary PortletMode and WindowState request during resource serving wit FULL cacheability Errata: PortletMode and WindowState request during resource serving wit FULL cacheability
        msnicklous made changes -
        Assignee msnicklous [ msnicklous ]
        Hide
        msnicklous added a comment -

        See the test portlet PORTLETSPEC3_26 in portletbox for tests that exercise the setting of header information and getting the WindowState and PortletMode (issue PORTLETSPEC3-27) in the resource phase.

        As it turns out, both WebSphere and Pluto return the PortletMode and WindowState information regardless of the cacheability setting on the URL.

        With the parameters, it's more complicated, and there is a difference between Pluto & WebSphere.

        Both portals provide the resource parameters (as opposed to render parameters) to serveResource() regardless of the cacheability setting. If cacheability is set to PORTLET or PAGE, both portals provide the public and private render parameters to serveResouce() as well.

        However, if cacheability is set to FULL, WebSphere provides neither the public nor the private render parameters to serveResource(), while Pluto provides ONLY the public render parameters to serveResource(). I think this is a bug in the Pluto implementation.

        But the big question is: How do we want it to be?

        Is it really necessary to suppress the render parameters, the PortletMode, and the WindowState when cacheability is set to FULL? Are there use cases that require that behavior? Or does it in some manner make it easier for a portal implementation if this information is not required to be present on a resourceURL with cacheability set to FULL?

        The current wording of the spec states:

        FULL – The resource URL does not need to contain the current state of the page or the current render parameters, portlet mode, or window state of the portlet.

        So it does not require this information to be present on a ResourceURL, but it does not forbid it, either.

        Shouldn't we just require it to be present, so that the parameter, window state, and portlet mode handling would not be dependent on the cacheability setting?

        I think we should answer these questions before making a clarification for this issue.

        Show
        msnicklous added a comment - See the test portlet PORTLETSPEC3_26 in portletbox for tests that exercise the setting of header information and getting the WindowState and PortletMode (issue PORTLETSPEC3-27 ) in the resource phase. As it turns out, both WebSphere and Pluto return the PortletMode and WindowState information regardless of the cacheability setting on the URL. With the parameters, it's more complicated, and there is a difference between Pluto & WebSphere. Both portals provide the resource parameters (as opposed to render parameters) to serveResource() regardless of the cacheability setting. If cacheability is set to PORTLET or PAGE, both portals provide the public and private render parameters to serveResouce() as well. However, if cacheability is set to FULL, WebSphere provides neither the public nor the private render parameters to serveResource(), while Pluto provides ONLY the public render parameters to serveResource(). I think this is a bug in the Pluto implementation. But the big question is: How do we want it to be? Is it really necessary to suppress the render parameters, the PortletMode, and the WindowState when cacheability is set to FULL? Are there use cases that require that behavior? Or does it in some manner make it easier for a portal implementation if this information is not required to be present on a resourceURL with cacheability set to FULL? The current wording of the spec states: FULL – The resource URL does not need to contain the current state of the page or the current render parameters, portlet mode, or window state of the portlet. So it does not require this information to be present on a ResourceURL, but it does not forbid it, either. Shouldn't we just require it to be present, so that the parameter, window state, and portlet mode handling would not be dependent on the cacheability setting? I think we should answer these questions before making a clarification for this issue.
        Hide
        Ed Burns added a comment -

        In general, I'm not fond of returning null. It's like throwing away valuable semantic information and getting back to a C-language type approach.

        Maybe it's better to add a new value to the PortletMode enum?

        Show
        Ed Burns added a comment - In general, I'm not fond of returning null. It's like throwing away valuable semantic information and getting back to a C-language type approach. Maybe it's better to add a new value to the PortletMode enum?
        msnicklous made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        msnicklous added a comment -

        To start off with, I answered my own question - on a resource URL will cache level set to FULL, neither the render parameters nor the portlet mode or window state should be present, as their presence would reduce the ability of the URL to be cached.

        Following Ed's suggestion to add a new value to the PortletMode and WindowState enum classes rather than return null, the values PortletMode.UNDEFINED and WindowState.UNDEFINED were added.

        The method definitions ResourceRequest.getPortletMode() and ResourceRequest.getWindowState() were added to ResourceRequest, overriding the corresponding definitions in PortletRequest, in order to add the description about the return value when the cache level is set to FULL.

        I went ahead and made the change without first posting a detailed proposal, because I felt the basic issue was clear. Naturally, if there would be reasons to modify the change, we can reopen the issue.

        Show
        msnicklous added a comment - To start off with, I answered my own question - on a resource URL will cache level set to FULL, neither the render parameters nor the portlet mode or window state should be present, as their presence would reduce the ability of the URL to be cached. Following Ed's suggestion to add a new value to the PortletMode and WindowState enum classes rather than return null, the values PortletMode.UNDEFINED and WindowState.UNDEFINED were added. The method definitions ResourceRequest.getPortletMode() and ResourceRequest.getWindowState() were added to ResourceRequest, overriding the corresponding definitions in PortletRequest, in order to add the description about the return value when the cache level is set to FULL. I went ahead and made the change without first posting a detailed proposal, because I felt the basic issue was clear. Naturally, if there would be reasons to modify the change, we can reopen the issue.
        msnicklous made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            msnicklous
            Reporter:
            julien_viet
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: