Each observer is hitting your rails app every 1.5 seconds. Any sort of poll hit on your server is going to have a negative impact on scaling.
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.
