FLUID-93: Viewing moved images after reordering, shows the incorrect image

Description

After initially moving an image. Clicking on a moved image will show the image now residing in its original location.

i.e. There are four images a, b, c, d in location 1, 2, 3, 4 respectively.

move image 'a' to position 3. new order is now b, c, a, d
clicking on image 'a' will show image 'b'
if you had clicked on image 'b' it will show image 'c' (as this was the original location for image 'b')

Note: once the page has been reloaded the images will display correctly.

Environments

firefox

Comments

• Michelle D'Souza commented 2007-11-15T10:53:00.000-0500

  This only happens in the gallery not in the stand alone lightbox.

  When a thumbnail is moved in the browser, the server reindexes the thumbnails but the client does not.

  In the above example a, b, c, d have indexes 0, 1, 2, 3.
  After moving 'a' to posiiton '3' the thumbnail order is b, c, a, d. The indexes on the client are 1, 2, 0, 3 but on the server are 0, 1, 2, 3.
  Clicking on 'a' requests the server for the thumbnail at index '0' which the client expects to be 'a'. However, the server has 'b' at index 0 and returns it instead.

• Eli Cochran commented 2007-11-26T13:30:39.000-0500

  This bug has been added to the Image Gallery JIRA http://jira.sakaiproject.org/jira/browse/GAL-68, assigned to Louis Majanja. This bug (here) should stay open since it's a Fluid release blocker.

• Antranig Basman commented 2007-11-28T16:40:09.000-0500

  This is not really a bug in the Fluid component, but reflects a use of URL space by the original app that can retrospectively seen to be invalid in this context.

  The issue is that the server and client are independently taking responsibility for reflecting the "reordering" operation - after the AJAX call, both client and server have reordered their respective collections. However, if the URL space applied for references within the client cells refers to collection elements by index, these indexes have now become "overpermuted" by the composition of the client and server operations. There are a few possible strategies for avoiding this problem, none of them very satisfactory:

  i) requiring a complete refresh of the managed area of the reorderer markup after each operation. This is fairly unacceptable since one of the main goals of the reorderer was to perform as many operations locally as possible.

  ii) nominate "invariant nodes" by specifying from the server parts of the client cell which should be "protected" from the permuting operation. This is also pretty awful since as Michelle pointed out the link text of the link to the image would need to be treated separately from the link target which really is a pretty unacceptably fine-grained markup division to expect to communicate to the client.

  There is no really satisfactory resolution except to forbid the use of index-based URLs within client cells which refer to elements within the managed collection by index, and to require globally stable ids instead. This would have caused a good deal of logic complication in the Gallery app if it was adopted as a global policy, but instead the problem was sidelined by adopting a "fat ViewParams" strategy which allows one style of URL to be used within the lightbox using ids, and another style to be used elsewhere using indexes - these URLs are considered equivalent designations of the same resource.

  This is resolved in the GAL-68 branch mentioned in the linked issue - no change is required to Fluid code.

• Justin Obara commented 2007-11-29T19:19:00.000-0500

  Verified the fix in firefox on winxp