Yes, I can see why it is needed in the code, however it just surprised 
me that it works if I use dragdrop.js from pre-1.6.x.

It is a serious limitation in large nested trees where you don't want to 
have to know what the lowest 'branch' is before you begin. For example, 
I have one extremely large tree that uses lazy creation of sortables. In 
the current situation that can lead to unsortable-sortables (!) as you 
can't ask a user to always make sure they sort there lowest nested items 
first ;-)

It also seems clumsy to use compared with other scripaculous wizardry, 
because the user has to remember how to use it depending on the 
structure of the dom, rather than just using it and the draggables 
looking after themselves. The 'draggables queue' is the problem here. 
Rather than ask a user to place items into the queue in the correct 
order, we probably need the order to be automated? Or for a different 
kind of storage.

I also use behaviour classes from lowpro, which very efficiently applies 
by behaviors as soon as elements are available in the dom...which is 
inconsistent with the bottom-first requirement.

Thanks for the feedback,

Pete.



Christophe Porteneuve wrote:
> Peter Robertson a écrit :
>   
>> If you create the sortable from most to least nested then it works (i.e. 
>>     
>
> You always need to do that when nesting draggables/sortables; this issue
> has surfaced several times in this list.
>
> This is fairly normal, as to implement d&d we need to convert a page
> position into an element, so when you have nested draggables (and
> sortables rely on draggables), you must create them from innermost to
> outermost: when going through the draggables queue, we'll hit a match on
> the innermost first if the mouse is indeed over it.
>
>   


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to