How to deal with observe_field in partials?

Hiyas

I’m having a little problem with a observe_field in a partial
“bokings/room_list”:

<%= select_tag “room_#{room.id}grownups", options_for_select([0, 1, 2],
room.grownups.length) %>
<%= observe_field "room
#{room.id}_grownups”,
:url => set_number_of_grownups_booking_room_url(:id => room.id),
:with => “‘number=’ + value”
%>

The set_number_of_grownups action does the job and then updates the
partial:

render :update do |page|
page[‘room_list’].replace_html :partial => “bookings/room_list”
end

The first time, everything works just fine. But subsequent changes of
the select fire the observer twice - at least to AJAX calls show up in
Firebug. (It happens with Safari, too.)

Maybe the old observer is still sitting around and gets a twin once the
partial is re-rendered. Strange though, no matter how often you change
that select, the number of fired AJAX calls is always 2. That’s on Rails
2 with Prototype 1.6.

Any ideas?

render :update do |page|
page[‘room_list’].replace_html :partial => “bookings/room_list”
end

The first time, everything works just fine. But subsequent changes of
the select fire the observer twice - at least to AJAX calls show up in
Firebug. (It happens with Safari, too.)

Maybe the old observer is still sitting around and gets a twin once the
partial is re-rendered. Strange though, no matter how often you change
that select, the number of fired AJAX calls is always 2. That’s on Rails
2 with Prototype 1.6.

Yes, could be. And since there is no way to assign the prototype
observer to a js variable, you can’t disable it before the call. Most
likely it’s the old observer triggered by the replace and then replaced
itself, so they don’t stack up infinitely, but get fired twice.

For you specific problem i don’t see, why you want to re-render the
whole select tag, since it’s options are constant anyway.

Worth a try may be splitting the partial and not reinstalling the
observer.

The hard way: Look at the generated code, take it as sample to write
your own observer, assigned to a variable name, so you can disable it
until the ajax response installs a new one.

By the way:

If it’s for select boxes only, you really don’t need an observer. You
can get similar results by using remote_function together with the
onchange event.

observe_field is more interesting for text fields where you would have
to hook into the keyevents to get similar results.

Thorsten M. wrote:

By the way:

If it’s for select boxes only, you really don’t need an observer. You
can get similar results by using remote_function together with the
onchange event.

observe_field is more interesting for text fields where you would have
to hook into the keyevents to get similar results.

Great, that’s the solution - and works like a charm with almost no
changes at all.

Thanks! -sven

Thorsten M. wrote:

For you specific problem i don’t see, why you want to re-render the
whole select tag, since it’s options are constant anyway.

There are more selects in the partial, in fact, our client has a rather
frowning matrix of dependencies between those selects which made it a
more realistic approach to just update the entire partial whenever any
select is changed.

Creating the observer by a hand-made helper certainly sounds better than
my own plan B:

(Move the observers out of the partial and then make sure all selects
are always present (yet hidden if necessary). One of the major browsers
(dont remember if it’s FF or IE) though will submit form fields
eventhough they are wripped by a display-none block element. Kinda
nasty, but a on-submit JS could remove those from the DOM beforehand.)

Strange that this is not a more common problem.