ICEfaces
  1. ICEfaces
  2. ICE-8008

After file upload, portlet reverts to pre-navigation view

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.1, EE-3.0.0.GA
    • Fix Version/s: 3.1.0.BETA1, 3.1
    • Component/s: ACE-Components, Framework
    • Labels:
      None
    • Environment:
      ICEfaces 3 ACE Portlet Portal
    • Assignee Priority:
      P1

      Description

      We have a test case (based on this forum entry http://jira.portletfaces.org/browse/BRIDGE-238) that shows that if you navigate to a second view in a portlet that contains a fileEntry component, the portlet will revert back to the original view once the fileUpload is executed.

        Activity

        Hide
        Deryk Sinotte added a comment -

        Attaching the test case. To run:

        1) Download and unzip.
        2) Copy the two folders (nav and nav-portlet) to icefaces/samples/showcase directory so that they can use the existing build infrastructure.
        3) From the nav-portlet directory, execute: ant clean liferay6.servlet-profile
        4) Copy the resulting .war file to the Liferay deploy directory (e.g. cp build/dist/*.war ~/Apps/liferay-portal-6.1.0-ce-ga1/deploy/)
        5) Once deployed, create a portal page and add the portlet to the page.

        To see the issue:

        1) Click on the "Go to Page 2" button.
        2) On the second view, choose a file and click the "Upload" button.
        3) Rather than stay on the view with the fileEntry component, it goes back to the original view.

        Show
        Deryk Sinotte added a comment - Attaching the test case. To run: 1) Download and unzip. 2) Copy the two folders (nav and nav-portlet) to icefaces/samples/showcase directory so that they can use the existing build infrastructure. 3) From the nav-portlet directory, execute: ant clean liferay6.servlet-profile 4) Copy the resulting .war file to the Liferay deploy directory (e.g. cp build/dist/*.war ~/Apps/liferay-portal-6.1.0-ce-ga1/deploy/) 5) Once deployed, create a portal page and add the portlet to the page. To see the issue: 1) Click on the "Go to Page 2" button. 2) On the second view, choose a file and click the "Upload" button. 3) Rather than stay on the view with the fileEntry component, it goes back to the original view.
        Hide
        Deryk Sinotte added a comment -

        This one was a bit hard to find but relatively easy to fix. It turns out that the PortletFaces Bridge was looking for a specific parameter that mapped to the current view id. The key (_facesViewId) was in the parameter map but namespaces by the portlet name. The full value would look something like this:

        testNavigation_WAR_navportlet_facesViewId=%2Fpage01.xhtml

        This value is stored in the map under the key "javax.faces.encodedUrl".

        In the FileEntryPhaseListener, there is some wrapping of the request to do some special handling of request parameters. The same logic is done in both the servlet and portlet version of the wrapper. The method in question is:

        public String getParameter(String name) {
        if (parameterMap != null) {
        if (!parameterMap.containsKey(name))

        { return null; }

        ...

        The wrapping wasn't considering the namespacing requirements that are done to portlet parameters and when the PortletFaces Bridge called getParameter to find find the value, it wouldn't find it in the map and would simply return null. What we needed to do was defer to the wrapped version of the request so that it could find the value that had already had the namespace processed.

        public String getParameter(String name) {
        if (parameterMap != null) {
        if (!parameterMap.containsKey(name))

        { //ICE-8008: defer to the actual request if the key can't be found return super.getParameter(name); }

        ...

        Show
        Deryk Sinotte added a comment - This one was a bit hard to find but relatively easy to fix. It turns out that the PortletFaces Bridge was looking for a specific parameter that mapped to the current view id. The key (_facesViewId) was in the parameter map but namespaces by the portlet name. The full value would look something like this: testNavigation_WAR_navportlet _facesViewId=%2Fpage01.xhtml This value is stored in the map under the key "javax.faces.encodedUrl". In the FileEntryPhaseListener, there is some wrapping of the request to do some special handling of request parameters. The same logic is done in both the servlet and portlet version of the wrapper. The method in question is: public String getParameter(String name) { if (parameterMap != null) { if (!parameterMap.containsKey(name)) { return null; } ... The wrapping wasn't considering the namespacing requirements that are done to portlet parameters and when the PortletFaces Bridge called getParameter to find find the value, it wouldn't find it in the map and would simply return null. What we needed to do was defer to the wrapped version of the request so that it could find the value that had already had the namespace processed. public String getParameter(String name) { if (parameterMap != null) { if (!parameterMap.containsKey(name)) { //ICE-8008: defer to the actual request if the key can't be found return super.getParameter(name); } ...
        Hide
        Deryk Sinotte added a comment -

        Checked in the change after testing file upload still works on portlets.

        Show
        Deryk Sinotte added a comment - Checked in the change after testing file upload still works on portlets.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: