Rails - Nov 2009 - bad move? - complex form with *many* observe_field's

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

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

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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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
<joegrossberg....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<joegrossberg....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<joegrossberg....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

BTW I vote "bad move" on this one :)

On Nov 30, 3:38 am,
"lancecarl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<lancecarl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<joegrossberg....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

On Nov 29, 10:50 pm, lunaclaire
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> So, actually it seems to working fine performance-wise...
... with one concurrent user. What happens when you have more, each of
whom has all these observers sending requests to the server every 1.5
seconds?

Also, depending on its audience, you will want to make sure this works
cross-browser.

Joe

--

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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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.

On Nov 29, 10:50 pm, lunaclaire
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<joegrossberg....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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,
"chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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,
"chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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,
"chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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,
"chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
>
> <chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

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,
"chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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,
"chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
>
> > <chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.

thx to all for the replies.

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.

On Dec 2, 12:03 am,
"lancecarl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<lancecarl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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,
"chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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,
"chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
>
> > > <chris.reis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
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.