I agree that it seems you have too many event observers on a single page. Because events in JavaScript "bubble up" to their parent elements you can accomplish all of these observations with a single event observer on the parent Form element. Then the callback function for that event can determine the proper response. You'll have to write some native JavaScript rather than using the rails shortcut for observe_field but it might ultimately be the cleaner approach.
On Nov 29, 10:50 pm, lunaclaire <[email protected]> wrote: > So, actually it seems to working fine performance-wise... but, it > still doesnt seem like quite the best arrangement. > > On Nov 27, 8:40 am, lunaclaire <[email protected]> wrote:> Thx for the > response, Joe. > > > I found that if I didnt have the the frequency set and relied on > > onchange, that it didnt always trigger when characters were input... > > it seemed to only trigger onblur when I'd move focus off the field. > > > But, I think that's another issue... > > > My concern is only partly the effect of a timer-based trigger on all > > these observers. I'm still wondering about having that many observers > > on a page in the first place. > > > On Nov 27, 5:57 am, Joe Grossberg <[email protected]> wrote: > > > > This sounds like it may be over-engineered. > > > > Why are you observing fields on a 1.5 second interval instead of using > > > the "onchange" attribute of your inputs and selects? > > > > Joe > > > > On Nov 26, 3: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.
