<commit_before>/**
  This helper class hides the ugly details of doing dragging in list views and tree views.

  One challenge in the implementation is how to designate a specific potential drop position.
  For a list of items, a natural choice would be to use an insert position: e.g. 0 would mean
  insert as the first item, 5 would mean insert as the fifth item. We can extend this for
  tree views by using an array of indexes: [2, 1, 4] would mean take the child number 2 from
  the topmost list, then child number 1 from the next, and insert the item as the fourth
  child of that. But there's an added complexity: When the item being moved is removed from
  its parent, all other items inside that parent shift, potentially changing the meaning of a
  path array. This means that while calculating a potential drop position, and when actually
  doing the insertion, positions potentially have a different meaning. It can be taken into
  account but it results into convoluted code.

  A better approach is to use unambiguous drop position designators. Such a designator can be
  constructed by naming an existing item in the tree (identified with a path *before* the
  item being moved is removed), and stating the insertion position relative to that. We need
  three insertion position indicators: before, after and inside (= as the first child, needed
  when there are currently no children at all). We can represent those as letters 'b', 'a' and
  'i'. This is handled in the nested Path class.

  In order to support dragging, items on all levels must provide a property 'childListView'
  that returns the view that has as its children all the items on the next level. If the
  object has nothing underneath it, it must return null.
  This is useful when the item views are complex and do not directly contain their child
  items as their only child views.

  See for example the following tree:

          A
         /|\
        / | \
       Z  X  Y
          |   \
          V    3
         / \
        2   4

  Here V is not ItemView but others are. Then A and Y should return itself, X should return V, and
  1 to 4 and Z should return null.
*/
Flame.ListViewDragHelper = Ember.Object.extend({
    listView: undefined,
    lastPageX: undefined,
    yOffset: undefined,
    itemPath: undefined,
    lastTargetContent: null,

    clone: undefined,
    mouseMoveCounter: 0,

    // Creates a clone of the dragged element and dims the original
    initReorder: function() {
        var newItemPath = Flame.ListViewDragHelper.Path.create({array: this.itemPath, root: this.listView});
        this.itemPath = newItemPath;
        // XXX very ugly...
        this.reorderCssClass = this.isTree() ? '.flame-tree-item-view-container' : '.flame-list-item-view';

        var view = this.itemPath.getView();

        // Don't set the opacity by using element-style but instead set appropriate class. Thus IE filters disappear
        // when they're no longer required for opacity. Plus this automatically restores the original opacity to the
        // element.
        view.set("isDragged", true);
        var element = view.$();
        var clone = element.clone();

        clone.attr('id', element.attr('id')+"_drag");
        clone.addClass('is-dragged-clone');
        clone.appendTo(this.get('listView').$());

        clone.css('opacity', 0.8);

        this.set('clone', clone);
        this._updateCss();

        // As the clone is not linked to any Ember view, we have to add custom event handlers on it
        var listView = this.get('listView');
        clone.mousemove(function(event) {
            listView.mouseMove.apply(listView, arguments);<commit_msg>Removed duplicate ids when dragging<commit_after>/**
  This helper class hides the ugly details of doing dragging in list views and tree views.

  One challenge in the implementation is how to designate a specific potential drop position.
  For a list of items, a natural choice would be to use an insert position: e.g. 0 would mean
  insert as the first item, 5 would mean insert as the fifth item. We can extend this for
  tree views by using an array of indexes: [2, 1, 4] would mean take the child number 2 from
  the topmost list, then child number 1 from the next, and insert the item as the fourth
  child of that. But there's an added complexity: When the item being moved is removed from
  its parent, all other items inside that parent shift, potentially changing the meaning of a
  path array. This means that while calculating a potential drop position, and when actually
  doing the insertion, positions potentially have a different meaning. It can be taken into
  account but it results into convoluted code.

  A better approach is to use unambiguous drop position designators. Such a designator can be
  constructed by naming an existing item in the tree (identified with a path *before* the
  item being moved is removed), and stating the insertion position relative to that. We need
  three insertion position indicators: before, after and inside (= as the first child, needed
  when there are currently no children at all). We can represent those as letters 'b', 'a' and
  'i'. This is handled in the nested Path class.

  In order to support dragging, items on all levels must provide a property 'childListView'
  that returns the view that has as its children all the items on the next level. If the
  object has nothing underneath it, it must return null.
  This is useful when the item views are complex and do not directly contain their child
  items as their only child views.

  See for example the following tree:

          A
         /|\
        / | \
       Z  X  Y
          |   \
          V    3
         / \
        2   4

  Here V is not ItemView but others are. Then A and Y should return itself, X should return V, and
  1 to 4 and Z should return null.
*/
Flame.ListViewDragHelper = Ember.Object.extend({
    listView: undefined,
    lastPageX: undefined,
    yOffset: undefined,
    itemPath: undefined,
    lastTargetContent: null,

    clone: undefined,
    mouseMoveCounter: 0,

    // Creates a clone of the dragged element and dims the original
    initReorder: function() {
        var newItemPath = Flame.ListViewDragHelper.Path.create({array: this.itemPath, root: this.listView});
        this.itemPath = newItemPath;
        // XXX very ugly...
        this.reorderCssClass = this.isTree() ? '.flame-tree-item-view-container' : '.flame-list-item-view';

        var view = this.itemPath.getView();

        // Don't set the opacity by using element-style but instead set appropriate class. Thus IE filters disappear
        // when they're no longer required for opacity. Plus this automatically restores the original opacity to the
        // element.
        view.set("isDragged", true);
        var element = view.$();
        var clone = element.clone();

        clone.attr('id', element.attr('id')+"_drag");
        clone.addClass('is-dragged-clone');
        clone.find("*").each(function() {
            this.id = this.id + "_drag";
        });
        clone.appendTo(this.get('listView').$());

        clone.css('opacity', 0.8);

        this.set('clone', clone);
        this._updateCss();

        // As the clone is not linked to any Ember view, we have to add custom event handlers on it
        var listView = this.get('listView');
        clone.mousemove(function(event) {
            listView.mouseMove.apply(listView, arguments);
{'fraction_non_alphanumeric': 0.07212632142379231, 'fraction_numerical': 0.004014452027298274, 'mean_word_length': 2.85059247810407, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5807427', 'n_tokens_mistral': 1974, 'n_tokens_neox': 1884, 'n_words': 969}