1) Depends what you have the observer do... Sounds like you are hitting your site every 3/4 of a second for the first hit, and 1.5 seconds after that now. If you are doing a save every time the observer fires. You can write an observer to call a local function instead of doing the AJAX save. but they whole point of doing AJAX saves is to send the data to the server.
2) You can observer a form.. calls a function that looks at the field type and does different work on the change... AKA, start a timer on text field, or call AJAX directly on select field. It is a simple if else on the local JS function. 3) You could remove all existing observers and create a new observer on every new event on a new field. But it would be a bit complex. maybe the onFocus() would work for everything? Not sure. onFocus removers all observers, and makes a new observer for the current field... You would not be able to move an observer around I would think. But this would make it seem like you were. Chris cowboyonrails On Nov 30, 8:40 am, lunaclaire <[email protected]> wrote: > 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.
