#2063 closed enhancement (wontfix)

Opened December 17, 2007 06:56AM UTC

Closed June 03, 2008 07:58AM UTC

Droppable accept function improvement

Reported by: mnichols Owned by: rdworth
Priority: major Milestone:
Component: ui.droppable Version: 1.5b4
Keywords: Cc:
Blocked by: Blocking:
Description

I am commonly needing to get the droppable element being targeted during an 'accept' callback to determine if the draggable signature is acceptable against the droppable element.

There isn't an easy way to get the droppable instance during this callback, so I changed draggable and droppable to use 'call' while passing in the droppable instance to force 'this' to always be the droppable being targeted during the accept callback.

Really, the 'ui' object should be getting passed in to this callback just like the other options to be consistent.

Please see attached patches or consider changing the method signature of this callback ... the function callback seems to have been an afterthought.

Attachments (0)
Change History (11)

Changed December 17, 2007 07:18AM UTC by mnichols comment:1

My draggable patch has a small error...it is passing the draggable instead of the draggable.element as other parts do.

Really, the documentation is wrong when it says that the draggable is passed to the accept callback since in fact the draggable.element is being passed.

Changed December 18, 2007 02:34AM UTC by rdworth comment:2

owner: → rworth
status: new → assigned

Changed January 05, 2008 09:50AM UTC by mnichols comment:3

Due to the complete rewrite of droppables recently, the first two patches are stale.

I have created a new patch that allows passing the 'ui' object from droppable into the accept function. This gives developer better options for determining if an draggable should be accepted based on criteria found in the target droppable.

Please see attached ' uidroppable-pass.ui.to.accept.patch '

and disregard the previous patches....

Mike

Changed January 08, 2008 05:25AM UTC by mnichols comment:4

I submitted #2122 that has this patch and a fix to the most recent trunk.

I'd recommend disregarding this patch to get the fix.

Mike

Changed January 21, 2008 05:02PM UTC by m0n5t3r comment:5

I think the above patch is a more elegant approach to passing the ui object as 

this
to the accept function

Changed January 21, 2008 09:52PM UTC by mnichols comment:6

does this work on the rewrite that was done on the trunk?

Changed January 23, 2008 03:27PM UTC by m0n5t3r comment:7

it's made against r4501, should apply cleanly to current trunk (the changes that have occurred since then are fn API changes, the ui part is unchanged)

Changed January 26, 2008 06:16PM UTC by mnichols comment:8

If I understand your patch, it seems your patch is passing the droppable (not ui) to be 

 this
.

The patch I submitted in #2122 passes the ui object as an arg the same as the other method calls. This is more intuitive I think than requiring the dev to back into the 

ui
object thru 
this
.

Changed May 24, 2008 03:39AM UTC by comment:9

milestone: 1.2.2

Milestone 1.2.2 deleted

Changed May 24, 2008 04:19PM UTC by paul comment:10

component: ui.core → ui.droppable
version: 1.2.1 → 1.5b4

Changed June 03, 2008 07:58AM UTC by scottgonzalez comment:11

resolution: → wontfix
status: assigned → closed

We will not expose plugin instances in any callback or event. Everything you need should be available from the DOM elements. If you really need to check properties of the instance, you need to do it on your own (this is highly discouraged as the internal API is able to change at any time).