So, is there any way to specify a sortable to only do a callback when the dragged item is dropped? As it is, the onChange is called whenever you move the draggable to a new element (even if you don''t drop it), but I''d rather only call my function after they drop it to avoid unnecessary additional server calls. It looks like Droppable supports an ''onDrop'', but Sortable doesn''t have a facility to pass that along. Any ideas? Greg
These blocks in the Sortable class need to be extended to provide the level of configurability you''re looking for: // build options for the draggables var options_for_draggable = { revert: true, ghosting: options.ghosting, constraint: options.constraint, handle: options.handle }; // build options for the droppables var options_for_droppable = { overlap: options.overlap, containment: options.containment, hoverclass: options.hoverclass, onHover: Sortable.onHover, greedy: !options.dropOnEmpty } -----Original Message----- From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Gregory Hill Sent: Monday, January 23, 2006 4:23 PM To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: [Rails-spinoffs] question about Sortables So, is there any way to specify a sortable to only do a callback when the dragged item is dropped? As it is, the onChange is called whenever you move the draggable to a new element (even if you don''t drop it), but I''d rather only call my function after they drop it to avoid unnecessary additional server calls. It looks like Droppable supports an ''onDrop'', but Sortable doesn''t have a facility to pass that along. Any ideas? Greg _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs The information transmitted in this electronic mail is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.
> These blocks in the Sortable class need to be extended to provide the > level of configurability you''re looking for: > > // build options for the draggables > var options_for_draggable = { > revert: true, > ghosting: options.ghosting, > constraint: options.constraint, > handle: options.handle }; > > // build options for the droppables > var options_for_droppable = { > overlap: options.overlap, > containment: options.containment, > hoverclass: options.hoverclass, > onHover: Sortable.onHover, > greedy: !options.dropOnEmpty > } >Well, yeah. But, then I have the maintainability problem when newer versions of scriptaculous are released. I was wondering if anyone knew a handy trick to accomplish what I wanted without modifying the library itself. Or if it were possible to have this option added into the trunk. Greg
Hey Greg, just my two cents: Why don''t you extend the classes and then make a patch for Thomas to integrate in the main distribution? Would be awesome to have those small, but needed extensions in there... greetings, benni. -SDG- Gregory Hill wrote:>> These blocks in the Sortable class need to be extended to provide the >> level of configurability you''re looking for: >> >> // build options for the draggables >> var options_for_draggable = { >> revert: true, >> ghosting: options.ghosting, >> constraint: options.constraint, >> handle: options.handle }; >> >> // build options for the droppables >> var options_for_droppable = { >> overlap: options.overlap, >> containment: options.containment, >> hoverclass: options.hoverclass, >> onHover: Sortable.onHover, >> greedy: !options.dropOnEmpty >> } >> > > Well, yeah. But, then I have the maintainability problem when newer > versions of scriptaculous are released. I was wondering if anyone knew > a handy trick to accomplish what I wanted without modifying the library > itself. Or if it were possible to have this option added into the > trunk. > > Greg > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
Well then maybe you can access the Sortable.options.droppables[] array, find the object you need, and then define an onDrop function for it, and likewise for the draggables and remove, add or otherwise override the handlers you need for each object. -----Original Message----- From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Gregory Hill Sent: Monday, January 23, 2006 4:35 PM To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: RE: [Rails-spinoffs] question about Sortables> These blocks in the Sortable class need to be extended to provide the > level of configurability you''re looking for: > > // build options for the draggables > var options_for_draggable = { > revert: true, > ghosting: options.ghosting, > constraint: options.constraint, > handle: options.handle }; > > // build options for the droppables > var options_for_droppable = { > overlap: options.overlap, > containment: options.containment, > hoverclass: options.hoverclass, > onHover: Sortable.onHover, > greedy: !options.dropOnEmpty > } >Well, yeah. But, then I have the maintainability problem when newer versions of scriptaculous are released. I was wondering if anyone knew a handy trick to accomplish what I wanted without modifying the library itself. Or if it were possible to have this option added into the trunk. Greg _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs The information transmitted in this electronic mail is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.
> Hey Greg, > > just my two cents: Why don''t you extend the classes and then make a > patch for Thomas to integrate in the main distribution? > > Would be awesome to have those small, but needed extensions inthere...>Yeah, I can do that; the main problem is that I don''t have svn access from work, so I can''t provide a diff file to him, which is his preferred method of receiving patches. It would be nice if every Effect class had an accessor to get a list of possible options, so that way when you have a combination effect, you can find out what options are usable to the underlying effects and pass them along. But then you''d have the problem of when multiple underlying effects have the same options, but you want to provide different ones to each. Anyhoo, for now, I''ll see about adding the onDrop option to Sortable and try to get a patch to Thomas. Greg
Thanks, man! I appreciate your effort a lot! greetings, benni. -SDG- Gregory Hill wrote:>> Hey Greg, >> >> just my two cents: Why don''t you extend the classes and then make a >> patch for Thomas to integrate in the main distribution? >> >> Would be awesome to have those small, but needed extensions in > there... > > Yeah, I can do that; the main problem is that I don''t have svn access > from work, so I can''t provide a diff file to him, which is his preferred > method of receiving patches. > > It would be nice if every Effect class had an accessor to get a list of > possible options, so that way when you have a combination effect, you > can find out what options are usable to the underlying effects and pass > them along. But then you''d have the problem of when multiple underlying > effects have the same options, but you want to provide different ones to > each. > > Anyhoo, for now, I''ll see about adding the onDrop option to Sortable and > try to get a patch to Thomas. > > Greg > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
Looks like Sortable already has an ''onUpdate'' option that should do exactly what I want. However, I cannot get it to fire. Has anyone had success with it? Passing the onDrop option along to Droppables didn''t work, either. It seems that onDrop is not consistently called because the ''last_active'' element is set to null almost all the time (in my tests). I''ll keep poking around through the code and see if I''m doing something wrong. Greg
On 1/23/06, Gregory Hill <Gregory_Hill-l9nu40+TWxQ@public.gmane.org> wrote:> > Looks like Sortable already has an ''onUpdate'' option that should do > exactly what I want. However, I cannot get it to fire. Has anyone had > success with it? >I use onUpdate with my sortables, and it does indeed do what you are looking for. For a usage example, see sortable5_test in the functional test directory. sortable4_test is also a good one to look at, although it uses onChange instead of onUpdate. _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs