Loading ...
Sorry, an error occurred while loading the content.

Re: [ydn-javascript] Dragdrop perfomance

Expand Messages
  • Peter Michaux
    HI, I don t know where I should submit documentation errors but I found this in the dragdrop code // initialize the groups array this.groups = {}; Should say
    Message 1 of 9 , May 31, 2006
    • 0 Attachment
      HI,

      I don't know where I should submit documentation errors but I found
      this in the dragdrop code

      // initialize the groups array
      this.groups = {};

      Should say object not array.

      Peter
    • Matt Warden
      ... They are using SourceForge to track bugs, and I have used it for documentation errors before. http://sf.net/tracker/?group_id=165715&atid=836476 You can
      Message 2 of 9 , May 31, 2006
      • 0 Attachment
        On 5/31/06, Peter Michaux <petermichaux@...> wrote:
        > HI,
        >
        > I don't know where I should submit documentation errors but I found
        > this in the dragdrop code
        >
        > // initialize the groups array
        > this.groups = {};
        >
        > Should say object not array.

        They are using SourceForge to track bugs, and I have used it for
        documentation errors before.

        http://sf.net/tracker/?group_id=165715&atid=836476

        You can also get to here by going to sf.net/projects/yui and clicking on 'bugs'

        --
        Matt Warden
        Oxford, OH, USA
        http://mattwarden.com


        This email proudly and graciously contributes to entropy.
      • Nige White
        ... The boolean isTarget can be set to false, then the DD instance is not a target. I think that the pattern used by the YAHOO DragDrop library might be
        Message 3 of 9 , Jun 1, 2006
        • 0 Attachment
          Peter Michaux wrote:

          >On 5/30/06, Adam Moore <adamoore@...> wrote:
          >
          >
          >> * The positions only need to be calculated for drag and drop elements that
          >> are in the group or groups the dragged element is assigned to. If you
          >> have a large number of instances, you may be able to improve performance
          >> by specifying unique groups for items that are not going to interact
          >> with items you assign to other groups.
          >>
          >>
          >
          >Here is another idea I started using today to inprove performance. I
          >have many draggable items in group Employee and only two drop targets
          >in group Employee. When I create each draggable I let it be added to
          >the default group (it is not in Employee). When I create each drop
          >target I add it to group Employee (it is not in default).
          >
          >When a draggable item has a mouse down event I add it to group
          >Employee and remove it from the default group (using delete
          >this.groups['default']). When this draggable has a mouse up even i
          >change it back to the default group. This way I never have more than
          >three objects in group Employee at a time. This could mean avoiding
          >maybe one hundred other possible group interactions.
          >
          >It would be nice to have in the library a removeFromGroup() method to
          >compliment addToGroup().
          >
          >This also implies the library could have a DDDraggable class which is
          >something that can only be dragged and never a target. This would
          >automatically change groups on mouse down and up events. DDDraggable
          >would compliment DDTarget. A possibility for the future?
          >
          >

          The boolean isTarget can be set to false, then the DD instance is not a
          target.

          I think that the pattern used by the YAHOO DragDrop library might be
          slightly flawed.

          To me, there should be a difference between a draggable object, and a
          target object.

          The drag events (onDragEnter, onDrag, onDragDrop and onDragOut) should
          be delivered to the draggable (as now), *and* the target. The target
          should get to decide what kind of action needs to be taken. The
          draggable probably doesn't know enough to actually implement any of
          these handlers. The *target* would do drop position highlighting, change
          the cursor type to indicate whether drop is possible, and handle the
          drop event creating a new object, and HTMLElement of it's own choosing.

          I have implemented this pattern on top of the current library in my
          DDTreeView/Draggable implementation, but I think that should be the
          pattern the library uses.

          The target will probably be a user-written object with methods of its
          own, so what's needed is an "interface" consisting of the four methods
          mentioned above - and a getElement() method to get the HTMLElement for
          which mousemove/mouseup event handlers are needed. Shame such things
          don't exist in javascript. You should be able to register your target
          objects with the DragDropMgr to receive events. Then as long as that
          registered object implements the event handling methods (implements the
          interface), your target object can react to drags and drops.

          I'll add an enhancement request.

          Nige

          _____________________________________________________________________
          This message has been checked for all known viruses. Virus scanning
          powered by Messagelabs http://www.messagelabs.com For more information
          e-mail : hostmaster@...
        • Peter Michaux
          ... Thanks for the info. I ll try this. So when I am dragging the libary only looks for interactions with possible targets? That would be nice and efficient
          Message 4 of 9 , Jun 1, 2006
          • 0 Attachment
            > The boolean isTarget can be set to false, then the DD instance is not a
            > target.

            Thanks for the info. I'll try this. So when I am dragging the libary
            only looks for interactions with possible targets? That would be nice
            and efficient like I was trying for with the groups games I was
            playing.

            > I think that the pattern used by the YAHOO DragDrop library might be
            > slightly flawed.
            >
            > To me, there should be a difference between a draggable object, and a
            > target object.
            >
            > The drag events (onDragEnter, onDrag, onDragDrop and onDragOut) should
            > be delivered to the draggable (as now), *and* the target. The target
            > should get to decide what kind of action needs to be taken. The
            > draggable probably doesn't know enough to actually implement any of
            > these handlers. The *target* would do drop position highlighting, change
            > the cursor type to indicate whether drop is possible, and handle the
            > drop event creating a new object, and HTMLElement of it's own choosing.
            >
            > I have implemented this pattern on top of the current library in my
            > DDTreeView/Draggable implementation, but I think that should be the
            > pattern the library uses.

            I agree it seems a little strange but I don't think it is a disaster.
            In my onDragEnter, onDragOut etc methods I have some "hey you" calls
            to get the target to pay attention. Things like

            Draggable.prototype.onDragEnter = function(e, id) {
            YAHOO.util.getDDById(id).heyYou();
            //..do other stuff
            };

            If the onDragEnter was delivered to the both the draggable and the
            target then which one will fire first? It might be better the way it
            is so that we can know the order things happen. I'm curious how you
            did implement it however.

            For you draggabble tree, did you make it so that items in an
            individual node can be reordered or just that items can be moved from
            node to node. I am looking at sortable lists too and will have to do
            something different than the Yahoo! example. I don't want the
            individual items to be targets. I want the node to be the target since
            the node's HTMLelement might be much bigger than the few elements
            inside.

            Peter
          • Nige White
            ... I do it in a similar way. In my example at https://secure0.forward-comp.co.uk/yui/examples/treeview/fcl.html I implement onDragEnter, onDrag, onDragDrop
            Message 5 of 9 , Jun 1, 2006
            • 0 Attachment
              Peter Michaux wrote:

              >> The boolean isTarget can be set to false, then the DD instance is not a
              >> target.
              >>
              >>
              >
              >Thanks for the info. I'll try this. So when I am dragging the libary
              >only looks for interactions with possible targets? That would be nice
              >and efficient like I was trying for with the groups games I was
              >playing.
              >
              >
              >
              >> I think that the pattern used by the YAHOO DragDrop library might be
              >> slightly flawed.
              >>
              >> To me, there should be a difference between a draggable object, and a
              >> target object.
              >>
              >> The drag events (onDragEnter, onDrag, onDragDrop and onDragOut) should
              >> be delivered to the draggable (as now), *and* the target. The target
              >> should get to decide what kind of action needs to be taken. The
              >> draggable probably doesn't know enough to actually implement any of
              >> these handlers. The *target* would do drop position highlighting, change
              >> the cursor type to indicate whether drop is possible, and handle the
              >> drop event creating a new object, and HTMLElement of it's own choosing.
              >>
              >> I have implemented this pattern on top of the current library in my
              >> DDTreeView/Draggable implementation, but I think that should be the
              >> pattern the library uses.
              >>
              >>
              >
              >I agree it seems a little strange but I don't think it is a disaster.
              >In my onDragEnter, onDragOut etc methods I have some "hey you" calls
              >to get the target to pay attention. Things like
              >
              >Draggable.prototype.onDragEnter = function(e, id) {
              > YAHOO.util.getDDById(id).heyYou();
              > //..do other stuff
              >};
              >
              >If the onDragEnter was delivered to the both the draggable and the
              >target then which one will fire first? It might be better the way it
              >is so that we can know the order things happen. I'm curious how you
              >did implement it however.
              >
              >For you draggabble tree, did you make it so that items in an
              >individual node can be reordered or just that items can be moved from
              >node to node. I am looking at sortable lists too and will have to do
              >something different than the Yahoo! example. I don't want the
              >individual items to be targets. I want the node to be the target since
              >the node's HTMLelement might be much bigger than the few elements
              >inside.
              >
              I do it in a similar way. In my example at
              https://secure0.forward-comp.co.uk/yui/examples/treeview/fcl.html

              I implement onDragEnter, onDrag, onDragDrop and onDragOut in my
              DDTreeView. When I construct the DDTarget for this, I override those
              methods in the DDTarget to call the corresponding events in the scope of
              the DDTreeView, so it's as if the DDTreeView *is* the target:

              // Make the tree droppable on. Extend this DDTreeView object to
              look like a DDTarget.
              this.ddTarget = new YAHOO.util.DDTarget(this.id, "menuTree");
              var _this = this;
              this.ddTarget.onDragEnter = function()
              {
              _this.onDragEnter.apply(_this, arguments);
              };
              this.ddTarget.onDragOver = function()
              {
              _this.onDragOver.apply(_this, arguments);
              };
              this.ddTarget.onDragDrop = function()
              {
              return _this.onDragDrop.apply(_this, arguments);
              };
              this.ddTarget.onDragOut = function()
              {
              _this.onDragOut.apply(_this, arguments);
              };

              It's a bit like my idea of being able to register any object as a
              DDTarget (as long as they implement these methods).

              The Draggable object (an extension of DDProxy) delivers the event, and
              itself to the target (the DDTreeView) on each of these events:

              /**
              This informs the recipient that it has been dropped upon.
              @return The object created as a result of the drop. It will be null
              if the target does not accept
              the drop.
              */
              Draggable.prototype.onDragDrop = function(e, id)
              {
              this.target = ((typeof id == "string") ?
              YAHOO.util.DragDropMgr.getDDById(id) : id[0]);
              return this.target.onDragDrop(e, this);
              };


              Nige

              _____________________________________________________________________
              This message has been checked for all known viruses. Virus scanning
              powered by Messagelabs http://www.messagelabs.com For more information
              e-mail : hostmaster@...
            Your message has been successfully submitted and would be delivered to recipients shortly.