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

        Deryk Sinotte created issue -
        Deryk Sinotte made changes -
        Field Original Value New Value
        Salesforce Case []
        Assignee Priority P1
        Assignee Deryk Sinotte [ deryk.sinotte ]
        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.
        Deryk Sinotte made changes -
        Attachment ICE-8008.zip [ 14300 ]
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #29002 Thu May 10 17:40:35 MDT 2012 deryk.sinotte ICE-8008: adjust wrapper so that it defers to wrapped request when searching for parameters
        Files Changed
        Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/fileentry/FileUploadPortletRequestWrapper.java
        Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/push/servlet/ProxyHttpServletRequest.java
        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.
        Deryk Sinotte made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Fix Version/s 3.1.0.BETA1 [ 10335 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: