Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-1148

Implement new "Drop Manager" for the Reorderer

    Details

      Description

      A great many bugs and inconsistencies, as well as performance issues, are caused by our use of the standard JQuery UI "ui.droppable" drop manager. These can only be decisively resolved by implementing a complete replacement for its drop model, which is more suited to the use case of reordering.

      In outline, the issues arise because of the "razor edged" drop target detection in ui.droppable - a drop target is only recognised if the mouse pointer is definitely within the bounds of the DOM element nominated as a "drop target". However, for the case of reordering, a more "soft-edged" approach is appropriate - there are many cases (e.g. FLUID-1125, FLUID-1127, FLUID-148) where the appropriate UI response is to map the drop target to the "geometrically nearest" position to the mouse cursor, rather than to either assume there is no target, or revert to the last target, which are the only two options available with the "razor edge" distance model.

      Also, several performance problems are traceable to ui.droppable - the "prepareOffsets" method is extremely expensive and is currently tied to the dragStart point of the lifecycle. It would be preferable to be able to compute the relevant DOM dimensions in user idle time after the drag proper has started. Finally, our use of the ui.droppable manager is awkward since the "left/right" logic required to spot previous/after drop targets has to be done by a raw mouse listener on a parallel lifecycle to the main drop notification. It would be preferable and more efficient to have this factored back behind a single, tractable interface, as well as to eliminate as much as we can of in-memory garbage created during a drag cycle.

      dev-iteration42

        Issue Links

          Activity

          antranig Antranig Basman created issue -
          antranig Antranig Basman made changes -
          Field Original Value New Value
          Link This issue is depended on by FLUID-1135 [ FLUID-1135 ]
          antranig Antranig Basman made changes -
          Link This issue is depended on by FLUID-33 [ FLUID-33 ]
          antranig Antranig Basman made changes -
          Priority Major [ 3 ] Critical [ 2 ]
          antranig Antranig Basman made changes -
          Link This issue is depended on by FLUID-1062 [ FLUID-1062 ]
          antranig Antranig Basman made changes -
          Assignee Antranig Basman [ antranig ]
          michelle.dsouza@utoronto.ca Michelle D'Souza made changes -
          Description A great many bugs and inconsistencies, as well as performance issues, are caused by our use of the standard JQuery UI "ui.droppable" drop manager. These can only be decisively resolved by implementing a complete replacement for its drop model, which is more suited to the use case of reordering.

          In outline, the issues arise because of the "razor edged" drop target detection in ui.droppable - a drop target is only recognised if the mouse pointer is definitely within the bounds of the DOM element nominated as a "drop target". However, for the case of reordering, a more "soft-edged" approach is appropriate - there are many cases (e.g. FLUID-1125, FLUID-1127, FLUID-148) where the appropriate UI response is to map the drop target to the "geometrically nearest" position to the mouse cursor, rather than to either assume there is no target, or revert to the last target, which are the only two options available with the "razor edge" distance model.

          Also, several performance problems are traceable to ui.droppable - the "prepareOffsets" method is extremely expensive and is currently tied to the dragStart point of the lifecycle. It would be preferable to be able to compute the relevant DOM dimensions in user idle time after the drag proper has started. Finally, our use of the ui.droppable manager is awkward since the "left/right" logic required to spot previous/after drop targets has to be done by a raw mouse listener on a parallel lifecycle to the main drop notification. It would be preferable and more efficient to have this factored back behind a single, tractable interface, as well as to eliminate as much as we can of in-memory garbage created during a drag cycle.
          A great many bugs and inconsistencies, as well as performance issues, are caused by our use of the standard JQuery UI "ui.droppable" drop manager. These can only be decisively resolved by implementing a complete replacement for its drop model, which is more suited to the use case of reordering.

          In outline, the issues arise because of the "razor edged" drop target detection in ui.droppable - a drop target is only recognised if the mouse pointer is definitely within the bounds of the DOM element nominated as a "drop target". However, for the case of reordering, a more "soft-edged" approach is appropriate - there are many cases (e.g. FLUID-1125, FLUID-1127, FLUID-148) where the appropriate UI response is to map the drop target to the "geometrically nearest" position to the mouse cursor, rather than to either assume there is no target, or revert to the last target, which are the only two options available with the "razor edge" distance model.

          Also, several performance problems are traceable to ui.droppable - the "prepareOffsets" method is extremely expensive and is currently tied to the dragStart point of the lifecycle. It would be preferable to be able to compute the relevant DOM dimensions in user idle time after the drag proper has started. Finally, our use of the ui.droppable manager is awkward since the "left/right" logic required to spot previous/after drop targets has to be done by a raw mouse listener on a parallel lifecycle to the main drop notification. It would be preferable and more efficient to have this factored back behind a single, tractable interface, as well as to eliminate as much as we can of in-memory garbage created during a drag cycle.


          dev-iteration42
          michelle.dsouza@utoronto.ca Michelle D'Souza made changes -
          Priority Critical [ 2 ] Blocker [ 1 ]
          antranig Antranig Basman made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          jobara Justin Obara made changes -
          Workflow jira [ 11180 ] Fluid [ 15082 ]
          jobara Justin Obara made changes -
          Workflow Fluid [ 15082 ] jira [ 18771 ]
          jobara Justin Obara made changes -
          Workflow jira [ 18771 ] Fluid [ 26443 ]
          michelle.dsouza@utoronto.ca Michelle D'Souza made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          jobara Justin Obara made changes -
          Workflow Fluid [ 26443 ] Fluid - triggers [ 37844 ]

            People

            • Assignee:
              antranig Antranig Basman
              Reporter:
              antranig Antranig Basman
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: