sortable implementation

[j-ro]

So...sortable needs a pretty different architecture than we have going I think.

This takes a list of nodes to be draggable, but sortable needs to take the parent container and then identify each node underneath it automatically. Given my limited knowledge of coffeescript and the lack of jQuery, I'm not sure how much headway I'll be able to make, because this is structured in a way that's very foreign to how I usually work.

[seiyria]

Well, what you can do: Create a DropSort on the container with some sortOptions (ie, prefix the options with sort), and then for each of that containers children, add a DropSort with drag- options. I think this might need some droppable zone functions though, which may pose a hindrance to working on sortable.

[j-ro]

Yeah, right -- what I was thinking of doing was replacing the dragged element in a sortable group with a temporary drop target, then moving that target up and down in the list based on mouse position, and on mouse up placing the dragged element where that temporary target is currently.

So maybe I should wait for your drop to see how things go. Here's what I have now, not really much at all:

http://plnkr.co/edit/MvzWxhIJuSmUUwvP3Nmq?p=preview

I've basically added a sortable bool option, that's about it.

[seiyria]

Perhaps. I wonder if you could make it possible to sort within a list without needing drop? That would be beneficial.

[j-ro]

Sure -- drop target is probably not necessary. But I do need to treat these things as a group, which the architecture doesn't really allow right now. I can't figure out whether the dropped item should be 1st or 2nd or 3rd in a row of items if I have no concept of a row.

[seiyria]

Well, suppose you created a DropSort with sortable=yes on the parent. Could you then go through its children, in order, and set an index value on it?

[j-ro]

Right, but methods like repositionItem take single nodes, and I'm not sure how then to feed it either the dragged node in that parent, or feed it the parent and then split it into its children based on the option bool.

[seiyria]

Well, repositionItem is just for dragging, so I'm not sure you'll need it for this. I think what you would need is the element after repositionItem is called on it, right? Since that would have the updated position and etc.

[j-ro]

hm...I guess. I want to designate a parent as sortable, and then that will allow me to drag a child element inside of it (using repositionItem on that element I think), and then there will be some conditional code in repositionItem that says if this is sortable (or I guess if this elements parent is sortable) then reposition drop targets based on mouse position and on mouseup, insert the dragged node into the correct position within the collection of elements inside the sortable parent.

[seiyria]

I see. So, the way I envisioned Sortable working was you would create a DropSort on the parent, and it would create one on all of its children (with the boundary element set to itself, so you can't drag outside of it?). Then you would just add some up, down, and move callbacks to the existing up, move, and down code (since you don't need to modify how it happens, you just need to do extra things during those events). Alternatively, you could add these functions to the parent DropSort, and just call them from the child DropSorts. I don't think you need to modify how repositionItem works, you just need to add some extra logic after it runs. Does that thought-process make sense?

[j-ro]

I think so, yes -- I just don't know how to do it :)

[seiyria]

That's okay! This is very much trial and error for me as well, so feel free to just try things. I think my approach above would work okay with the current architecture, so maybe try that, and if it's a huge problem, we could work out a desired structure to make it better?

[j-ro]

Sure -- I guess I'm fairly unclear about how the interpreter flows through the code. So, for example, if I were to take the first option (create a dropsort on the parents with a sortable option and then have logic to create that in the children too), where would I go to apply that logic? What function reads the options and goes first, so I can intercept it setting up the wrong thing?

[seiyria]

So if you look at the constructor, it does this:

    do @doInitialVariableCalculations
    do @addBinding
    @mouse = new MouseAction @element

    # need some form of easy way to determine what to call
    do @setupDrag

You'll probably want variable calculations, and the binding, and the mouse action. So.. maybe just make a switch at the bottom for doing a setupSortable instead of a setupDrag

[j-ro]

ok, cool, so:

http://plnkr.co/edit/ILpM3uy6IueeUTxf2VAx?p=preview

I now have those two setup functions, but I seem to have broken regular dragging when the sortable option is false and I'm not sure why

[seiyria]

So you might notice in setupDrag I have a bunch of mouse-handling events that are bound. You'll have to bind similar ones or abstract / reuse the ones I've created.

[j-ro]

oh, totally -- my issue is that I've broken something about the original functionality. With sortable set to false, I should be able to drag around the UI element I've set as the DropSort element, but I can't.

[seiyria]

Yes, that's because you say "if sortable, then do setupSort" but setupSort doesn't set up any of the mouse handling, which is why it isn't working, at least that's what I'm seeing.

[j-ro]

Yes, but in my plunk the sortable option is set to false, so it should not hit setupSort

[seiyria]

Honestly, I'm at a loss for how you did it. The diff of the two files is not that large. Could you fork this plunk and try adding it again (sorry)? This time maybe keep one of the draggables in place and try to drag it every time you make a small change. I don't think it's volatile, but I think there's something odd that neither of us is picking up.

[j-ro]

I know! It's not! I'll try the fork, sure, we'll see how it goes. But that was basically what I did -- forked something working, then added my bit of code, and then no working.

[j-ro]

well, it's working over here:

http://plnkr.co/edit/8DEXWiSF1oRRC7xZeU4O?p=preview

Will continue on this as I can, let's see

[seiyria]

I've pushed a droppable implementation.

[j-ro]

Nice, looks pretty good! I'll see if I can get time to continue on my end soon.

[seiyria]

Great. I'm also going to try to implement a sortable control - we'll see how far I get. I'll start with a single-list and then expand to multi, so feel free to check my progress in the plunk (though I wouldn't expect anything for a while - I'm still designing).

[seiyria]

At present, I have a 1-list sortable: http://plnkr.co/edit/vDHEzoEZwmkIGtKh91DR?p=preview

Nothing about connecting them yet - that's up next. First I have to make a few more features (like a placeholder, and better insertion algorithm), then I'll be moving on to that.

[j-ro]

oh, nice! Sorry I've been MIA a bit, crazy few weeks at work...

[seiyria]

No worries. this is my current work project so I have a bit more time to dedicate to it, since it's become a necessity.

[j-ro]

Ah, very cool -- better to tie it to something you're actually working on any way, better results that way I've found. My work project involves quick loading and sorting a 7,000 member multiselect, which browsers really don't like. :)

[seiyria]

Ew! :( Yeah, I've been trying to get around it with jQuery UI and it just wasn't cutting it anymore. Now I can build in all the features I want :D

[seiyria]

Now I have a single-element sortable! I have to fix up a few algorithms but that should be good to go by the end of today, I think. After that I'll move on to multi-sortables.

[j-ro]

Looks pretty good! I'll not that it's hard to get an element on the bottom, it seems to want to put something second to last rather than last. I can take a look when I hopefully have some time soon...

[seiyria]

Yeah, it currently just uses insertBefore. That's one of the things on my list to fix up -- after that, dragging elements between sortables. Then some code cleanup.

[seiyria]

Gonna close this. I have a few more features to add, but the core functionality works.

[j-ro]

Small bugs here: If I drag something nonsortable to the side of a sortable element, then I drag an item in the sortable, the position of the nonsortable jumps. Not sure how the CSS is aligning but these jumps should not happen I'd guess.

I also want to note an opinion on the multiselect implementation -- it feels rather nonintuitive for me. Basically, I think the grouping should be let go after a sort.

Right now, you click one item, click another (to select both), then drag to sort. Then if you click another item it adds to your selection. I didn't expect that. Rather, after a drag, I expected to start my selection from scratch again.