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.
