Hello all,
I''m using Sortables to create a sort of appointment book, and once we
got into using it with the live data, the page started to take forever
to load. We''ve got about 50-60 items to a page and the load time is
somewhere between 15 and 30 seconds on some older machines at the
client''s office (and our old Windows tester box). Once it''s
loaded,
the script is fairly repsonsive, but since it''s being used to make
appointments over the phone, a 30 second load time is proving to be a
bit of an obstacle.
My code basically looks like this:
var lists =
Array(''thing1'',''thing2'',''thing3'',......,''thing55'');
for(i=0;i < list.length;i++)
Sortable.create(lists[i], {dropOnEmpty:true, tag: ''p'',
containment:
lists});
Has anyone run into a problem like this? Any tips on
fixing/optimization?
Thanks,
Jeff
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
It''s a problem for us too. Even worse is the delay when dragging. The load delay can be mitigated by doing some just-in-time declaration: create the sortable (or individual Draggables) on mouseover. The delay while dragging (which you didn''t complain about, but will in the future, I''m sure) is caused because the position of all of the elements are checked on each mousemove. I''ve been thinking about ways of caching position to speed up processing (a la JQuery?), but haven''t put the pen to paper, so to speak. TAG tomg-PGZyUNKar/Q@public.gmane.org On Jan 22, 2007, at 10:37 AM, Jeff wrote:> > Hello all, > > I''m using Sortables to create a sort of appointment book, and once we > got into using it with the live data, the page started to take forever > to load. We''ve got about 50-60 items to a page and the load time is > somewhere between 15 and 30 seconds on some older machines at the > client''s office (and our old Windows tester box). Once it''s loaded, > the script is fairly repsonsive, but since it''s being used to make > appointments over the phone, a 30 second load time is proving to be a > bit of an obstacle. > > My code basically looks like this: > var lists = Array(''thing1'',''thing2'',''thing3'',......,''thing55''); > > for(i=0;i < list.length;i++) > Sortable.create(lists[i], {dropOnEmpty:true, tag: ''p'', containment: > lists}); > > Has anyone run into a problem like this? Any tips on > fixing/optimization? > > Thanks, > Jeff > > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 24, 7:42 am, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org> wrote:> The delay while dragging (which you didn''t complain about, but will > in the future, I''m sure) is caused because the position of all of the > elements are checked on each mousemove. I''ve been thinking about > ways of caching position to speed up processing (a la JQuery?), but > haven''t put the pen to paper, so to speak.I don''t think that''s the right answer. If the pointer must overlap the drag visual, the "donut drag" is the right approach. This creates four clones of the drag visual and crops each one to leave a hole of 3x3 (or so) pixels in the middle, around the pointer hot spot. That way the browser does the hit testing for you (lightening fast) and the drag target is in the event object. This of course means that the actual draggable isn''t the drag visual; you need four of those. The scriptaculous D&D module is pretty simple but a bit too primitive really, and there is a number of small errors and oversights in the code, things that look like they should work but don''t. I started making fixes, but I''m certain that proper fixes will create some incompatibilities... how attached are people to backward compatibility issues? Clifford Heath. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
What oversights have you encountered? I''ve looked at the doughnut technique, and while effective for limited application, may I suggest two problems: 1. Under certain CSS conditions (I think it involved padding--I don''t recall the specifics) IE doesn''t map the onenter/onexit events to the right area. (It''s been a while since I played with it, and it was testing for a different purpose, so I could be mistaken here.) 2. Creating the doughnut is extremely difficult for an arbitrary div with unknown contents, especially text. (What if the Draggable is a table?) A workaround for problem #2 is offsetting the Draggable from the cursor by 1px on mousedown, but that doesn''t have the natural feel of an intuitive draggable. TAG On Jan 24, 2007, at 8:02 PM, Clifford Heath wrote:> > On Jan 24, 7:42 am, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org> wrote: >> The delay while dragging (which you didn''t complain about, but will >> in the future, I''m sure) is caused because the position of all of the >> elements are checked on each mousemove. I''ve been thinking about >> ways of caching position to speed up processing (a la JQuery?), but >> haven''t put the pen to paper, so to speak. > > I don''t think that''s the right answer. If the pointer must overlap > the drag visual, the "donut drag" is the right approach. This creates > four clones of the drag visual and crops each one to leave a hole > of 3x3 (or so) pixels in the middle, around the pointer hot spot. > That way the browser does the hit testing for you (lightening fast) > and the drag target is in the event object. This of course means > that the actual draggable isn''t the drag visual; you need four of > those. > > The scriptaculous D&D module is pretty simple but a bit too primitive > really, and there is a number of small errors and oversights in the > code, things that look like they should work but don''t. I started > making fixes, but I''m certain that proper fixes will create some > incompatibilities... how attached are people to backward compatibility > issues? > > Clifford Heath. > > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 25, 3:16 pm, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org> wrote:> What oversights have you encountered?It was before Xmas when I last looked at it, so I''m not sure I correctly recall the details. I wanted first and foremost to fix the "drag outside scrollable DIV" problem with a systematic fix, and that required cloning the draggable to a parent (but then that causes different styles to apply, urk). I had in mind to build a reliable tree widget that can handle D&D in large trees, such as the excellent one Jack Slocum has done in yui-ext. So I tried fiddling around with stuff related to ghosting and the handle attribute. It seemed that the logical thing was to use "handle" to address the drag visual (the clone). It was awkward, as many parts of the code that should use "handle" actually use "element" instead, so I needed to work out exactly which ones to correct - the actions on completion still needs to do stuff to "element". Some of the actions folk might attach would need the clome and some the draggable too. The side effect of this fix would be that the use of the handle option would work in a wider range of situations - it''s pretty limited at present IIRC - I think handle doesn''t work with ghosting or something. I figured if I could get it to work in all obvious cases by dragging a clone, I could augment the clone to be a donut or +1px object, so that was the longer-term goal on the way to a tree. Anyhow after making slow progress (though I''m a mature programmer I don''t have much browser, JS & CSS exp) and when I came here for help, google didn''t deliver my messages and I thought you were all ignoring me, so I dropped it.> 1. Under certain CSS conditions...Perhaps... but yui-ext handles ok it so it must be feasible.> 2. Creating the doughnut is extremely difficult for an arbitrary divI expect so. I''d suggest that in most cases you don''t want to drag a clone of a structured element anyhow, but just a "handle", which can be limited to a simple element that''s otherwise invisible. The limited support that scriptaculous has for this reflects its history in sorting images; not a general type of D&D at all. If anyone''s interested in helping sort some of these issues, I''m open to suggestions (at first.last-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org). Clifford Heath. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---