[Rails] Re: bad move? - complex form with *many* observe_field's

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.html#M001655

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 <szager...@gmail.com> 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 rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.