Thx for the responses... a couple of my own: 1) is it true that these hit my app (i.e. the server)? I asked the question thinking the issue would be on the client side only ala Chris' response... if there's no change, it doesnt seem to call the autosave fxn, so I dont think I'm getting the server-side hit
2) I tried observe_form first, but the issue is that I have some text fields that I want to observe one way (after text changes every few secs) and some selects I want to observe another way (only onchange)... but it seemed to get triggers only in whichever way I chose for the form, so I'm not sure this can work for my case 3) finally, not sure I asked this clearly at the start, but is there some way to dynamically "move" the observer (on the text field at least) to the currently focused field and only have one? On Nov 30, 6:52 am, "[email protected]" <[email protected]> wrote: > 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... > > 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.
