Portallayout, portalchildren ordering storage, possible bug

asked 2013-11-04 11:25:12 +0800

krzysztofgenge
1

Hi,

I have a problem with preserving portalchildren order (handled in onPortalMove event). If the user drags a child and drop it to the same position in the same portallayout the onPortalMove event witch is fired has wrong ordering of elements, despite the fact that the gui view is rendered correctly. Now if I preserve the information from onPortalMove event to database than after refresh it causes the view to order differently than it was set by the user. If you dragged first element and dropped to first position the DroppedIndex is 1 in 0 based scale. If you drop this element a position after then you also get DroppedIndex as 1. Thats why I cannot distinguish the proper and false event data -> two different giu actions starts exacly the same event action.

Please let me know if you have similar expirience with portallayout. Does anybody has an idea for a workround?

I have posted a bug: ZK-1997

Steps to recreate:

1. Go to the ZK Drag and Drop demo at www.zkoss.org/zkdemo/layout/portal_layout

2. Put all portal elements into first column (this step is not mandatory)

3. Make page refresh (f5) to see that the portal view is recreated properly through session
4. Drag first portal element and drop it to the location it was dragged from (first position)
5. The view is rendered properly (nothing changes) ,but in onPortalMove event that is handled in method @Listen("onPortalMove = #portalLayout") public void saveStatus() { int i = 0; for (Component portalChild : portalLayout.getChildren()) { List<string> portletIds = new ArrayList<string>(); for (Component portlet : portalChild.getChildren()) portletIds.add(portlet.getId()); Executions.getCurrent().getSession().setAttribute("PortalChildren" + i++, portletIds); } } the portalLayoutChildren elements (portalLayout.getChildren()) are passed in wrong order -> the dragged element is on the second position in the list, like it was moved one position down. This wrong state is saved in session
6. Now refresh the page (f5) and you will notice that the portallayout view recreated from the session state has changed (the first element is moved to the second position although it shouldn't)