The best way I have found to do this is to observe the form, (you can observe an entire form with one observer).
http://api.rubyonrails.org/classes/ActionView/Helpers/PrototypeHelper.html#M001655 Another thing I have done i the past is have the observer fire off a javaScript function, that sets a Timeout of 2 seconds (or some number) and stores a value, then if the observe_form fires again, I clear the last timeout, create a new time out. This way your save function is called on the server only when they user has stopped typing for 2 seconds. It is a neat trick that has saved me millions of hits on my server. I have noticed that having many observers on a page can cause client side performance problems. You may not feel them on your machine, but Not all machines swallow JavaScript the same. Your clients may feel a lot more performance problems than yourself on something like that. Chris On Nov 26, 12:19 pm, lunaclaire <[email protected]> wrote: > I have a pretty complex form with many text fields and a number of > selects. We let the user add multiple types of associated objects to > the parent object and to edit the values for those associated objs, so > the form can have something like the following number of fields on the > page: > > 9 text fields + 3 selects + a*(1 text + 1 select) + b*(1 text + 1 > select) + c*(1 text + 1 select) + d*(1 text + 1 select) + e*(1 text + > 1 select) + f*(7 text + 1 select) > > where the a, b, c, etc are the number of the diff types of assoc objs. > > Also, it's designed to have an autosave function. I've taken an > approach that is working, but I'm concerned that it may not be the > best, mostly from a performance aspect. > > Each of the text fields has an observe_field set up for it with > a :frequency => 1.5 (this seemed to be the best setting for this to > catch rapid typing without droopping chars while the autosave is > performed). > > And each of the selects observe_field() does not have the frequency > set, so that it calls the autosave fxn only on change (vs when the > user is scrolling over the choices). > > Anyway, does anybody see a prob having *lots* of observers like this > set up on a page? Seems like there could be a prob with having that > many observe_fields set up for the text fields triggering on a > frequency basis. > > If so, one workaround I thought of was to leave the select observers > in place and have one observe_field for the currently focused > text_field to reduce the number number triggering every 1.5 secs. > > But, if that sounds good, how would I dynamically change the DOM ID of > that single observer? Or kill the prev one and create a new one for > the newly focused field? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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-talk?hl=en.
