ICEfaces
  1. ICEfaces
  2. ICE-2118

DnDCache instance uses only the current portlet as context

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.6.1
          • Fix Version/s: 1.7DR#3, 1.7
          • Component/s: ICE-Components
          • Labels:
            None
          • Environment:
            Portal(Liferay)
          • Workaround Exists:
            Yes
          • Workaround Description:
            Hide
            I've managed to solve this by placing the key into the application session, not portlet session so all portlets would share the same DnDCache. Here's the code:

            public static DnDCache getInstance(FacesContext context, boolean encoding) {
                    PortletSession portletSession = (PortletSession)context.getExternalContext().getSession(false);

                    DnDCache cache = (DnDCache) portletSession.getAttribute(SESSION_KEY,PortletSession.APPLICATION_SCOPE);
                    if (cache == null) {
                        cache = new DnDCache();
                        portletSession.setAttribute(SESSION_KEY, cache, PortletSession.APPLICATION_SCOPE);
                    }
                    return cache;
                }

            However, this code is not yet standardized to your current structure to use portal context detection, so if you run this in a servlet environment it would not work.

            It would be nice if you could look into it and if you consider it's a good solution, make the necessary adjustments or comments on my ideea.

            Thanks,

                Dan Leahu.
            Show
            I've managed to solve this by placing the key into the application session, not portlet session so all portlets would share the same DnDCache. Here's the code: public static DnDCache getInstance(FacesContext context, boolean encoding) {         PortletSession portletSession = (PortletSession)context.getExternalContext().getSession(false);         DnDCache cache = (DnDCache) portletSession.getAttribute(SESSION_KEY,PortletSession.APPLICATION_SCOPE);         if (cache == null) {             cache = new DnDCache();             portletSession.setAttribute(SESSION_KEY, cache, PortletSession.APPLICATION_SCOPE);         }         return cache;     } However, this code is not yet standardized to your current structure to use portal context detection, so if you run this in a servlet environment it would not work. It would be nice if you could look into it and if you consider it's a good solution, make the necessary adjustments or comments on my ideea. Thanks,     Dan Leahu.

            Description

            ------------------- DnDCache.java
            public static DnDCache getInstance(FacesContext context, boolean encoding) {
                    String viewId = context.getViewRoot().getViewId();
                    Map map = context.getExternalContext().getSessionMap();
                    DnDCache cache = (DnDCache) map.get(SESSION_KEY);
                    if (cache == null) {
                        cache = new DnDCache();
                        map.put(SESSION_KEY, cache);
                    }
                    return cache;
                }

            ------------------- ISSUE
            The instance taken using this method for the DnDCache is in the context of the current running portlet. Hence, if a drag was made from one portlet to another, the dragValue and dropValue properties would be null because the DnDCache instance is local to the source portlet.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Deryk Sinotte added a comment -

              Assigning to Adnan to make the actual change in the DnDCache.

              I've examined and test the supplied code fix. It's my opinion that it's safe to use it as is. A couple of things to note.

              1) Make sure we use the appropriate environment detection (servlet vs portlet) logic to execute the desired logic.

              2) Do not introduce any runtime dependencies on the Portlet libraries.

              3) If #2 requires the use of reflection or other potentially expensive operation, ensure that we do it efficiently (i.e. only do the detection once).

              Show
              Deryk Sinotte added a comment - Assigning to Adnan to make the actual change in the DnDCache. I've examined and test the supplied code fix. It's my opinion that it's safe to use it as is. A couple of things to note. 1) Make sure we use the appropriate environment detection (servlet vs portlet) logic to execute the desired logic. 2) Do not introduce any runtime dependencies on the Portlet libraries. 3) If #2 requires the use of reflection or other potentially expensive operation, ensure that we do it efficiently (i.e. only do the detection once).
              Hide
              Permalink
              Adnan Durrani added a comment -

              Fixed 15087.

              Tested with the tomcat in the non-portlet environment, no run time dependency was found.

              Show
              Adnan Durrani added a comment - Fixed 15087. Tested with the tomcat in the non-portlet environment, no run time dependency was found.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              I guess it works. I did get some flakiness in Firefox where it would leave Draggable boxes on the screen. Not sure if it was caused by dragging too fast or what. Safari looks like it has some problems with the Drag n Drop in general. I'm not entirely convinced that we have the whole solution here. We may need to sit down and think a bit about what drag and drop between portlets really means.

              Show
              Deryk Sinotte added a comment - I guess it works. I did get some flakiness in Firefox where it would leave Draggable boxes on the screen. Not sure if it was caused by dragging too fast or what. Safari looks like it has some problems with the Drag n Drop in general. I'm not entirely convinced that we have the whole solution here. We may need to sit down and think a bit about what drag and drop between portlets really means.
              Hide
              Permalink
              Adnan Durrani added a comment -

              will do.

              Show
              Adnan Durrani added a comment - will do.

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  Dan Leahu
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: