I think onChange was the better implementation.. You might even want to put in a delay to wait for them to stop typing for a second or two.
On Dec 1, 2:44 pm, "[email protected]" <[email protected]> wrote: > 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.
