Relocate event doesn't seem to work about nestedsortable

[ilikenwf]

Since you seem to have figured it out, would you mind putting in a pull request for the change needed to fix?

[DrSchizo]

I'm sorry, I tried to find where the real problem is but I failed. My OOP JS knowledge is very slight. All I can say is that on the _mouseStop event (line 377), the aswer to the if test on line 406 is always "false".

Indeed, the two following statements are always true:
1/ $(this.domPosition.parent).parent().attr("id") == this._uiHash().item.parent().parent().attr("id")
2/ $(this.domPosition.prev).next().index() == this._uiHash().item.index()

The ids and the indexes returned are always the one of the dragged element BEFORE it is moved.

[ilikenwf]

I'll take a look when I get a chance, or maybe someone can before I do - depends on my schedule.

Thanks for trying anyway!

[ilikenwf]

@twicejr mind taking a look?

[DrSchizo]

Thank you a lot.

There is no hurry for me since I've triggered the move is allowed (!=revert). The event is triggered to often (even when the item hasn't move), but it works anyway ;-)

One nice addition would be to pass as arguments of the relocate function the new and the old position of the item. For instance, my script is saving the new location in real time, and not only after clicking on a "save" button. I managed to do it by exporting the toArray output and comparing it with a saved version, but it could have been not much easier to do, especially since the previous and current index and parent id should be retrieved in the script just before triggering the relocate event (at least, once the bug will be fixed).

[twicejr]

@DrSchizo , I assume you did NOT forget the comma after the change function, as in your sample code?
Will look into it when I have time. I think whatever.parent().parent().attr("id") is not a very elegant solution anyway!

[DrSchizo]

No, I didn't. The code hasn't been written made by me. The mistake is in the file "jquery.mjs.nestedSortable.js". The two comparisons in the if test are always true and therefore the test always fails.

var pid = $(this.domPosition.parent).parent().attr("id");
var sort = this.domPosition.prev ? $(this.domPosition.prev).next().index() : 0;

if(!(pid == this._uiHash().item.parent().parent().attr("id") &&
sort == this._uiHash().item.index())) {
this._trigger("relocate", event, this._uiHash());
}

You can see the bug by adding this code below:
console.log('pid = '+pid+' and '+this._uiHash().item.parent().parent().attr("id"));
console.log('sort = '+sort+' and '+this._uiHash().item.index());

[twicejr]

I think we should solve this in a similar way I coded the disableParentChange functionality.
//pseudo code:
!(oldParent.is(newParent) && oldItem.index() == newItem.index())

[tfddev]

I ran into the same problem. Perhaps the proposal below will solve the problem.
(It does seem to work as expected in my tests)

It seems there's just a small flaw in the if... else... logic. (See below).
(Can you verify this solution?)

/*
// ORIGINAL CODE
if (!(pid == this._uiHash().item.parent().parent().attr("id") &&
sort == this._uiHash().item.index())) {
this._trigger("relocate", event, this._uiHash());
}
*/

// POSSIBLE SOLUTION
var isRelocated = false;
if (pid !== this._uiHash().item.parent().parent().attr("id")) {
isRelocated = true;
} else if( sort !== this._uiHash().item.index() ) {
isRelocated = true;
}
if (isRelocated) {
this._trigger("relocate", event, this._uiHash());
}

[tfddev]

See:
https://github.com/tfddev/nestedSortable

[ilikenwf]

If you solved it, please put in a pull request.

On Sat, Sep 20, 2014 at 9:19 PM, TFD - DevDept [email protected]
wrote:

See:
https://github.com/tfddev/nestedSortable

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

[GlobetechAG]

I'm afraid tfddev's proposal does not solve the problem. The underlying problem still is as DrSchizo mentioned:
"The ids and the indexes returned are always the one of the dragged element BEFORE it is moved."

[twicejr]

It is fixed and tested in the latest version.