Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#3695 closed task (fixed)

Explore the possiblity of chaining movers functionality.

Reported by: Eugene Lazutkin Owned by: Eugene Lazutkin
Priority: high Milestone: 1.0
Component: DnD Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description

In some cases the mover should be augmented at the time of creation. This way different constraints and additional tasks can be performed.

Attachments (2)

move.js (11.3 KB) - added by guest 12 years ago.
Suggested enhancment from T.J. Crowder - see comment
movertest.html (3.6 KB) - added by guest 12 years ago.
Test page for suggested enhancement from T.J. Crowder - see comment

Download all attachments as: .zip

Change History (11)

comment:1 Changed 12 years ago by Eugene Lazutkin

Status: newassigned

Changed 12 years ago by guest

Attachment: move.js added

Suggested enhancment from T.J. Crowder - see comment

Changed 12 years ago by guest

Attachment: movertest.html added

Test page for suggested enhancement from T.J. Crowder - see comment

comment:2 Changed 12 years ago by guest

Hi all,

I've attached my suggested update to move.js as Eugene and I discussed (http://dojotoolkit.org/forum/support/general-support/dojo-0-9-drag-move-notification), as well as a quick-and-dirty test page (movertest.html) demonstrating the features.

I've made these changes:

Mover:

  • The constructor now has a third "opt" parameter for miscellaneous options, rather like Moveable's "opt" param. The default mover doesn't have any optional options (yet).
  • Its specializations are now subclasses rather than functions returning updated anonymous prototypes.
  • Has a central moveNode method that actually moves the node, so subclasses have a central method to override. This just calls Moveable's new move method (below).
  • Publishes the dndMoveStart and dndMoveStop events passing in the Moveable, rather than the node; receiver can get the node from Moveable.node. This is so receivers can hook the Moveable's events if they want to.

Moveable:

  • Constructor has a new "moveropt" optional parameter in the 'opt' object, containing options to pass to the Mover constructor when needed.
  • Has a new public move method that actually moves the underlying node.
  • Mover-controlled moves are started by calling the internal _startMove method.
  • Mover-controlled moves are ended by calling the internal _endMove method.
  • Now has the following events:
    • onStartMove(Moveable,Mover) - When a move operation starts.
    • onEndMove(Moveable) - When a move operation ends.
    • onMoving(Moveable,Point) - During a move operation, when we're about to move the node but haven't yet; caller can override the Point to apply simple constraints.
    • onMoved(Moveable,Point) - During a move operation, after we've moved the node.
  • Renamed the marginBox internal member to cursorOffset to better reflect how it's used.
  • In various places where we were using point instances, called them "pt" rather than "box".
  • Fixed a minor bug related to the user moving the mouse completely out of the browser and releasing the mouse button, we could end up (briefly) with two Movers attached to the Moveable if the user clicks the node again (since it's following the cursor around).

The new events give the user of the API a great deal of flexibility without needing to subclass or specialize anything -- for instance, most constraints could be applied simply by hooking the onMoving event, and of course onMoved provides the notification I was originally looking for. However, Mover is still written to allow subclasses, for those situations where you need more context (ParentConstrainedMover is a good example of this - you could do it with the events, but it would be awkward to reuse).

While doing this, I noticed a bug in the parent constraint stuff (I first noticed it in my updated version, took me a while to realize that it exists in the original as well) in that it gets thrown off by absolutely-positioned parents. I haven't fixed it, I'll file a separate bug report on it. If I have time in the next couple of days, I'll try to fix it.

I haven't looked to see whether these changes break anything using dnd in the base Dojo 0.9. If you like this and want to use it, we can look to make sure.

--
T.J. Crowder
tj at crowder software dot com

comment:3 Changed 12 years ago by Eugene Lazutkin

Milestone: 1.01.1

comment:4 Changed 12 years ago by Eugene Lazutkin

(In [11089]) dnd: partial refactoring of dnd.move, which preserves the old API, but provides new facilities, refs #3695.

comment:5 Changed 12 years ago by Eugene Lazutkin

(In [11090]) dnd: constraints implemented with special Moveables instead of Movers, refs #3695.

comment:6 Changed 12 years ago by Eugene Lazutkin

Resolution: fixed
Status: assignedclosed

comment:7 Changed 12 years ago by bill

Milestone: 1.11.0

comment:8 Changed 12 years ago by Eugene Lazutkin

Milestone: 1.01.0.1

comment:9 Changed 12 years ago by bill

Milestone: 1.0.11.0

(this has already been fixed, that's why it's marked as milestone 1.0)

Note: See TracTickets for help on using tickets.