Ruby on Rails | Screencasts | Download | Documentation | Weblog | Community | Source

Ticket #3379 (new enhancement)

Opened 4 years ago

Last modified 3 years ago

draggables are stuck in a div with overflow:scroll. A way to move them to upmost dom level needed

Reported by: Martin Scheffler Assigned to: Rails
Priority: normal Milestone: 1.2.7
Component: script.aculo.us Version: 1.0.0
Severity: normal Keywords: dragdrop overflow
Cc: bellis@deepthought.org

Description

when I define a draggable in a div that has a style overflow:scroll or overflow:auto, I can't drag the draggable out of this div. The scrollbars in the div get longer according to the position of the draggable, but there is no way to get it out.

Why is this needed: I have a long list of draggables that are in a list scrollable with the overflo:auto scroll area. I want to drag them to a droppable shopping cart like div.

I rewrote the dragdrop.js so that it runs when ghosting and revert are activated, but it gives errors when ghosting is disabled.

It works like this: When a draggable is dragged, it gets appended to document.body and its position is set so that it does not appear to move. On drag stop, it gets reattached to its former position.

Here is a diff for dragdrop.js ( i think it's for version 1.5)

192c192 < /*reverteffect: function(element, top_offset, left_offset) { ---

reverteffect: function(element, top_offset, left_offset) {

195,222c195 < },*/ < reverteffect: (function(element, top_offset, left_offset) { < var dur = Math.sqrt(Math.abs(top_offset2)+Math.abs(left_offset2))*0.02; < new Effect.MoveBy(element, -top_offset, -left_offset, < {duration:dur, < afterFinish:(function(){ < < if(this.onFront) { < this.onFront=false; < < this._clone.parentNode.insertBefore(this.element,this._clone); < this.element.style.left=this._clone.offsetLeft+"px"; < this.element.style.top=(this._clone.offsetTop-this._clone.parentNode.scrollTop)+"px"; < < Position.relativize(this.element); < < if(this.options.ghosting) { < < Element.remove(this._clone); < this._clone = null; < } < < } < < }).bind(this) < }); < }).bind(this), < ---

},

262,267c235 < if(Event.isLeftClick(event)) { < < if(this.onFront) { < return; < } < ---

if(Event.isLeftClick(event)) {

298c266 < if(this.options.ghosting && !this.onFront) { ---

if(this.options.ghosting) {

304,328d271 < if(this.options.bringtofront && !this.onFront) { < this.onFront=true; < pos=Position.page(this.element); < /*var d = this.currentDelta(); < if(revert && this.options.reverteffect) { < this.options.reverteffect(this.element, < d[1]-this.delta[1], d[0]-this.delta[0]); < */ < this.delta=pos; < < //this.originalLeft = pos[0]; < //this.originalTop = pos[1]; < this.originalZ=1000; < document.body.appendChild(this.element); < < var pointer = [Event.pointerX(event), Event.pointerY(event)]; < this.offset[0]=(pointer[0] - pos[0]); < this.offset[1]=(pointer[1] - pos[1]); < < this.element.style.left=pos[0]+"px"; < this.element.style.top=pos[1]+"px"; < < < } < 349c292 < if(this.options.ghosting && !this.options.bringtofront) { ---

if(this.options.ghosting) {

Attachments

patch_dragdrop_tofront.diff (2.3 kB) - added by Martin Scheffler on 01/03/06 19:20:07.
Sorry, diff got screwed up. Here it is again

Change History

01/03/06 19:20:07 changed by Martin Scheffler

  • attachment patch_dragdrop_tofront.diff added.

Sorry, diff got screwed up. Here it is again

01/03/06 23:04:42 changed by dz@bitxtender.com

  • priority changed from low to normal.
  • severity changed from minor to normal.

I discussed this with Thomas some time ago, and the problem is that the element we move (be it in ghosting mode or not) usually must remain at the same DOM level because otherwise, styles might get lost. I'm working on a solution right now, too, it will involve a new option you can use to assign a class name to the element while it's being dragged. If this class name is supplied, the element will be attached to the body. Let's see if this works, I'll provide the patch as soon as it is ready

01/06/06 17:00:51 changed by bellis@deepthought.org

  • cc set to bellis@deepthought.org.

Just hoping to listen in. I've been looking for the same functionality but haven't had a chance to try it myself.

01/13/06 18:50:26 changed by blog@andrewdupont.net

Also interested in a solution to this; I'm hacking together a temporary fix right now. Perhaps instead of a class name (or as an alternative), the user can give an array of styles he wants inherited from the original element (applied using Element.getStyle)? I've got a nested list in which I want each LI to be a draggable, and so I want the cloned element to inherit padding-left and font-size from the original element.

01/19/06 03:46:07 changed by anonymous

Any word on this? We could really use it for a production demo due out in a couple weeks.

02/19/06 22:41:01 changed by dev.rubyonrails@llpots.com

Would love to see this worked out as well.

03/26/06 15:26:37 changed by kaine@phoenixpo.com

Listening in as well. I tried applying the diff changes manually (took me three and a half hours to look through many tools and papers to see if I was doing it incorrectly), but no luck (using Firefox 1.5 as test).

As for my use, the item tags are children of the div tag, the items having their own class, independent of the div. I am moving items between two overflow-y:scroll divs.

04/12/06 14:48:44 changed by anonymous

i would also loooove this feature!

04/28/06 02:12:28 changed by Clint

Still no movement on this, huh?

I tried the fixes to prototype and dragdrop at http://dev.rubyonrails.org/ticket/2685, however the don't seem to be working for me on Firefox 1.5.2.

05/04/06 18:37:11 changed by anonymous

this seems to be a growing request, as I also want to this same effect. Any status on this?

05/05/06 16:51:03 changed by Clint

I too would like to see this worked into the main scriptaculous code. It's highly annoying I almost had to scrap the library for my production code.

For those of you still looking, this one worked for me:

http://wiki.script.aculo.us/scriptaculous/revision/EffectsTreasureChest?rev=18

It's under the heading 'overflow: scroll hack and draggable element substitution' three quarters of the way down the page.

05/09/06 19:19:15 changed by tomg@byu.net

I too would like to see something like this implemented. I ended up getting around it by trapping the onclick, manually creating a "ghost" at a higher DOM level (also had to manually set the height/width/position as none of the Prototype functions did it quite properly), and setting the new "ghost" to be Draggable.

The "options.ghostClass" solution mentioned above would be easier, but it has some pitfalls: if you're dragging a <li>, it can't simply create a <li> as a child of document.body; the same is true for <tr>.

Besides, you can already observe the "onDrag" event (create an event observer) to add a special class to the ghost, or override options.starteffect and achieve the same result. I don't think adding another option (or at least a "ghostClass" option) is the solution here.

(in reply to: ↑ description ) 03/04/07 18:48:18 changed by mwillson

I too would really like to see this implemented.

I can live with whatever styling glitches might occur due to an element being moved to body - I'd be happy if you just make this an option for me (with a proviso that I may need to tweak my stylesheet appropriately if I enable the option).

Currently I'm getting around this in a hacky way, by using ghosting and subclassing Draggable to make the ghosting work in a way that suits me better. But I still have a bug with the positioning of the draggable being off when the parent div is scrolled down.