ICEfaces
  1. ICEfaces
  2. ICE-2520

ICEfaces Ajax requests should generate ActionRequests in portal environments.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7DR#3
    • Fix Version/s: 2.0-Beta1
    • Component/s: Bridge, Framework
    • Labels:
      None
    • Environment:
      Portal portlet

      Description

      The current behaviour of ICEfaces in a portal environment is for the initial request to go through the portal container, generating a RenderRequest. The RenderRequest is handled by our own MainPortlet which routes it to the MainServlet and the rest of the ICEfaces framework. In a portal environment, typical client interaction with a portlet would also go through the portal container, generating an ActionRequest. Currently, ICEfaces does not do this. All client interaction is done via Ajax and the resulting requests go straight to our own framework servlets, bypassing the portal container. This has a number of consequences for the developer (some of which are documented in other JIRA cases):

      - Session last accessed time is not updated properly
      - ActionRequest/ActionResponse APIs are not available to the portlet developer preventing programmatic control of things like portlet modes (view, edit, help, etc) and window states (minimized, maximized, etc)

        Issue Links

          Activity

          Hide
          Mircea Toma added a comment -

          The user session is no more than the session associated with the web-application deployed in the ROOT context, namely the portal implementation. The portlet session is backed by a servlet session associated to the web-application corresponding to the deployed WAR.

          So, I attempted to fix this issue by creating an action URL (PortletResponse.createActionURL) and then invoke it every time portlet's corresponding "lastAccessTime" is touched. But because every action request will trigger a render in all portlets this solution is not viable.

          The solution might be to just monitor the portal session and when is about to expire invoke an action URL that would force a page refresh and consequently update the "lastAccessTime" time of the portal session (== ROOT context). The good thing is that the implementation could be isolated just to the MainPortlet class.

          Show
          Mircea Toma added a comment - The user session is no more than the session associated with the web-application deployed in the ROOT context, namely the portal implementation. The portlet session is backed by a servlet session associated to the web-application corresponding to the deployed WAR. So, I attempted to fix this issue by creating an action URL (PortletResponse.createActionURL) and then invoke it every time portlet's corresponding "lastAccessTime" is touched. But because every action request will trigger a render in all portlets this solution is not viable. The solution might be to just monitor the portal session and when is about to expire invoke an action URL that would force a page refresh and consequently update the "lastAccessTime" time of the portal session (== ROOT context). The good thing is that the implementation could be isolated just to the MainPortlet class.
          Hide
          Mircea Toma added a comment -

          See duplicate issue – ICE-2519.

          Show
          Mircea Toma added a comment - See duplicate issue – ICE-2519 .
          Hide
          Deryk Sinotte added a comment -

          Assigning to Deryk and targetting for 2.0 when we can look at using the new Portlet 2.0 spec for better async support.

          Show
          Deryk Sinotte added a comment - Assigning to Deryk and targetting for 2.0 when we can look at using the new Portlet 2.0 spec for better async support.
          Hide
          Deryk Sinotte added a comment -

          General and proper portlet support for ICEfaces 2.0 falls under the parent issue of the JSF Portlet Bridge.

          Show
          Deryk Sinotte added a comment - General and proper portlet support for ICEfaces 2.0 falls under the parent issue of the JSF Portlet Bridge.
          Hide
          Ken Fyten added a comment -

          Assign to Neil for consideration as part of the PortletFaces Bridge integration work.

          Show
          Ken Fyten added a comment - Assign to Neil for consideration as part of the PortletFaces Bridge integration work.
          Hide
          Neil Griffin added a comment -

          ICEfaces 2.0 uses the JSF 2.0 standard mechanism for submitting Ajax requests using the jsf.js JavaScript library. The PortletFaces bridge has a method named ExternalContext.encodeResourceURL that will generate a Portlet 2.0 javax.portlet.ResourceRequest which is the Portlet 2.0 way of doing Ajax. We won't be generating ActionRequest, but ResourceRequest, but I think this issue should be closed anyway as the spirit of the goal has been reached.

          Show
          Neil Griffin added a comment - ICEfaces 2.0 uses the JSF 2.0 standard mechanism for submitting Ajax requests using the jsf.js JavaScript library. The PortletFaces bridge has a method named ExternalContext.encodeResourceURL that will generate a Portlet 2.0 javax.portlet.ResourceRequest which is the Portlet 2.0 way of doing Ajax. We won't be generating ActionRequest, but ResourceRequest, but I think this issue should be closed anyway as the spirit of the goal has been reached.

            People

            • Assignee:
              Neil Griffin
              Reporter:
              Deryk Sinotte
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: