Skip to main content

Search and Top Navigation

#3749 closed bug (duplicate)

Opened January 03, 2009 03:07AM UTC

Closed October 03, 2012 03:06PM UTC

Sortable: Specifications needed

Reported by: rdworth Owned by:
Priority: blocker Milestone: 2.0.0
Component: ui.sortable Version: 1.6rc4
Keywords: Sortable specs specifications Cc:
Blocked by: Blocking:
Description

Section 3 - Functional Specifications/Requirements on http://jqueryui.pbwiki.com/Sortable need to be written. Should include more than just a listing of API options. See http://jqueryui.pbwiki.com/Slider for an example.

Attachments (0)
Change History (9)

Changed January 20, 2009 04:26PM UTC by paul comment:1

resolution: → fixed
status: newclosed

Changed January 20, 2009 06:01PM UTC by paul comment:2

resolution: fixed
status: closedreopened

Changed March 08, 2009 02:30PM UTC by rdworth comment:3

milestone: 1.71.8

Changed February 24, 2010 05:14PM UTC by rdworth comment:4

milestone: 1.81.next

Changed October 19, 2010 03:47PM UTC by scottgonzalez comment:5

milestone: 1.next1.9
priority: criticalblocker

Changed May 20, 2011 04:02PM UTC by jdmarshall comment:6

I can't speak for anyone else, but I can tell you what I need, in brief:

New functionality/bug fixes:

1) The placeholder needs to follow the helper more closely. Currently you can drop and item while the helper is on the opposite side of the screen. This leads to some pretty bad interactions with the other bugs in sortable

2) Somehow, elements that are not currently visible need to have lower precedence than items that are. Scrollable sortables wreak havoc on DnD operations.

3) Sub O(n) intersection testing. For any large number of sortable items the linear scan takes too long, especially on IE7, and is too inaccurate (see later commentary)

I can think of 3 general solutions to this problem. Some sort of 2d sort perhaps, but for my purposes searching for intersecting connectWith sortables and only then descending into them would probably suffice (most of my problems occur on pages with many drop targets). Otherwise, intersection test should be able to pick all relevant items, and then pick the best fit, not just the first that looks good.

Keepers, aka please don't break these:

1) Dragging anywhere below the last item in the Sortable append()s the placeholder to the sortable.

2) Scrolling (actually this could be better)

3) Ability to reject a drag operation (eg, beforeStop() { return false; })

4) Ability to reject after an ajax call (I do this by identifying the original location of the item from the event data)

5) Ability to drag the actual item

6) Reflow on drag (nice to have)

7) Clickable items inside of draggable ones (in my case, hyperlinks in the items)

8) Ability to set a move cursor

Changed December 16, 2011 12:02AM UTC by jdmarshall comment:7

_comment0: I've spent a lot more time poking around the code now and I have another request. \ \ It turns out that most of the time spent in sortable() relates to calculating the size of the 'items'. That's a pretty expensive proposition for large sortables, especially if all of the sortables are of uniform size. \ \ So for each element you look up half to a dozen CSS rules, then repeat it for the next element. It would be nice to either be able to provide hints, or for the sizing code to notice that most of the sorted items have identical CSS and look it up once. \ \ 1324057973839610

I've spent a lot more time poking around the code now and I have another request.

Each sortable has a full table of every other item in its connectWith containers. Probably the containers should do their own thing. This starts to get pretty bad even with only 3 containers, because you get 9 entries for each item. So that's probably priority 1, and could be fixed as part of a breadth-first search solution (ie, find the containers I'm intersecting with, then ask them about their items, rather than keeping my own cache).

Beyond that, it turns out that most of the time spent in sortable() relates to calculating the size of the 'items'. That's a pretty expensive proposition for large sortables, especially if all of the sortables are of uniform size.

So for each element you look up half to a dozen CSS rules, then repeat it for the next element. It would be nice to either be able to provide hints, or for the sizing code to notice that most of the sorted items have identical CSS and look it up once.

Changed February 02, 2012 06:53PM UTC by scottgonzalez comment:8

milestone: 1.91.next

Changed October 03, 2012 03:06PM UTC by scottgonzalez comment:9

milestone: 1.next2.0.0
resolution: → duplicate
status: reopenedclosed

Duplicate of #6172.