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
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?
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.
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.
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.
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?
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.
Turns out they changed the design away from autosave after I built it.
That happens doesnt it?
But, when I get a chance, I'm gonna try what Chris suggested in regard
to the "moving the observer" idea. If I get something useful, I'll
come back to this thread and post it.
