canceling drag between connected lists drops item #107

Activity

1. thgreasi commented on Jan 29, 2014

   

   thgreasi

   on Jan 29, 2014

   Contributor

   More actions

   You should use the model to count the length of the list, not the DOM elements.
2. ghost assigned

   dimirc

   on Jan 29, 2014
3. ghost assigned

   thgreasi

   on Jan 29, 2014
4. brendanblackwood commented on Jan 29, 2014

   

   brendanblackwood

   on Jan 29, 2014

   Author

   More actions

   Fair enough. The same problem will persist, however. Canceling the sort will replace the item in the proper place in the DOM, but it will not replace the model. That just gets lost.

   New codepen with model checking: http://codepen.io/anon/pen/fAvCJ
5. thgreasi commented on Jan 29, 2014

   

   thgreasi

   on Jan 29, 2014

   Contributor

   More actions

   Here is the order that the events fire on connected lists:

   strart      0
   activate    1
   activate    0
   update      0
   remove      0
   receive     1
   update      1
   stop        0
   

   As far as I know the best time to call cancel() is inside the first update callback. Receive and update on the receiving list is too late, since the first model has already been altered.
   Here is a pen utilizing the changes of #108.

   Feel free to reopen if necessary.
6. thgreasi

   closed this as completedon Jan 29, 2014
7. brendanblackwood commented on Jan 30, 2014

   

   brendanblackwood

   on Jan 30, 2014

   Author

   More actions

   Works great. Thanks!
8. jegesh commented on Mar 14, 2016

   

   jegesh

   on Mar 14, 2016

   More actions

   How would I go about cancelling a drag between lists, but allowing ordering within a list, only for certain elements (validation)? When I try to cancel when remove fires from the original list, the element stays put, but becomes unorderable thereafter. Debugging it, I see that ui.item.sortable.model is undefined.
9. thgreasi commented on Mar 14, 2016

   

   thgreasi

   on Mar 14, 2016

   Contributor

   More actions

   You can place your logic in the update callback and use the properties of
   the ui.item.sortable object (ui is the second argument of the callback).
   Take a look at the examples and documentation in README.md and API.md .

   Thodoris Greasidis
   Computer, Networking &
   Communications Engineer
10. jegesh commented on Mar 14, 2016

    

    jegesh

    on Mar 14, 2016

    More actions

    I tried doing that, but I need to know if it's just a sort within the list, or moving to a second list. There is no indication of this until either the second update is hit, or remove of the first list gets hit, in either too late to cancel the action, because the update call of the original list happens before that. I'm looking for a way to either determine already in the first update if it's a move or an ordering, or alternatively a way to 'manually' call the update callback from within the remove callback of the same list.
11. thgreasi commented on Mar 14, 2016

    

    thgreasi

    on Mar 14, 2016

    Contributor

    More actions

    As noted in API.md, you can use the droptarget and droptargetModel properties and possibly compare them with source and sourceModel properties, to check whether it's a connected-list sorting.
12. thgreasi commented on Mar 14, 2016

    

    thgreasi

    on Mar 14, 2016

    Contributor

    More actions

    The comparison of droptarget should look like source[0] !== droptarget[0] since both of them are jQuery Collection Objects.
    An other of doing this would be by using the moved property (even though I don't prefer it and it might get deprecated).
13. jegesh commented on Mar 15, 2016

    

    jegesh

    on Mar 15, 2016

    More actions

    I'm sorry, maybe I'm dense, but I feel like you didn't read my last comment very closely. The problem I'm having is with the timing of the cancellation. If I cancel after I know if it's a reorder or a move, then the source list has already been updated, and cancelling producing the situation mentioned by the PO above, wherein the draggable is neither here nor there - it appears to be in the list, but it's missing from the sourceModel array. So I need to postpone the update until I know if it's a move or just a reorder, and then fire it, or decide not to.
14. thgreasi commented on Mar 15, 2016

    

    thgreasi

    on Mar 15, 2016

    Contributor

    More actions

    Please provide an example of your use case by forking one of the codepen
    examples found in README and I will do my best to help you. If delayed
    cancellation is all that you need, you can take a look at the "promised
    cancellation" example.

    Thodoris Greasidis
    Computer, Networking &
    Communications Engineer
15. jegesh commented on Mar 16, 2016

    

    jegesh

    on Mar 16, 2016

    More actions

    Thank you so much for your assistance. Examining the 'promised cancellation' example I was able to come up with a satisfactory workaround. I'm posting my code in case it might be of help to someone else in the future:

    var _immovableItem = null;
    $scope.sortableOptions.list1 = {
              connectWith:".list2",
              activate: function(){
                _immovableItem = null;
              },
              remove: function(e, ui){
                if (isInvalid(ui.item.sortable.model) {
                  ui.item.sortable.cancel();
                  _immovableItem = ui.item.sortable.model;
                }
              },
              stop: function(e, ui){
                if (_immovableItem) {
                  ui.item.sortable.sourceModel.push(_immovableItem);
                  $timeout(function(){
                    $(e.target).find("li").last().remove();
                  });
                }
              }
            };
            $scope.sortableOptions.list2 = {
              connectWith: ".list1",
              update: function (e, ui) {
                if(isInvalid(ui.item.sortable.model)){
                  ui.item.sortable.cancel();
                }
              }
            };
    

    Essentially, what's happening here is that in the first list, where I want to keep items that don't pass validation but allow them to be reordered within it, I perform validation on every update. If the item doesn't pass validation, I store it in the _immovableItem variable for later use. Then, if the item gets removed from that first list, I know the user is attempting to move it, which I don't want to allow, therefore I cancel the remove (which only prevents it from being removed from the DOM of the first list, but not the data model), cancel the update into the second list, and after everything has settled down (i.e. in a $timeout function), manually add the item back to the data model of the first list, and manually remove the orphaned <li> left over at the end of the list.