I'm trying to get an ajax search feature together for one of my
views. When my user types a name fragment into a text input box, the
browser makes an ajax call, passing search parameters, and dumps the
results into a <div>. I've got it basically working with render :text
in the respond_to block, but I need to send an html table w/the
results in it & so that's not going to work w/out doing serious
violence to separation of concerns. The obvious choice would seem to
be an html partial, but it looks like rails is expecting a js partial
in that branch of respond_to. Is there a graceful way of telling
rails that I really want the results from my html partial?
Here's some code to make it concrete. Here's the relevant part of the
view:
def search
respond_to do |format|
@project_people =
ProjectPerson.find_person_by_name_fragment(params[:q], params[:p])
format.js {render(:partial => 'project_people', :locals => {:pp =>
@project_people })}
# format.js {render :text => "frag is '#{params[:q]}' and project
is '#{params[:p]}'" }
# format.js {render :text => debug(params) }
end
end
As is, that gets me "ActionView::ActionViewError in Project
peopleController#search"
Couldn't find template file for project_people/_project_people in
["C:/railsapps/collabtrac/app/views"]
I do indeed have a file called C:/railsapps/collabtrac/app/views/
project_people/_project_people.html.erb. If I deviously rename that
to ..._people.js.erb, then it seems to work (suprising--I would have
thought erb would have been screwed up by the disinformation in the
extension).
Sooo... I suspect I'm pretty far off the intended track here--this
seems kludgy at best. Who's got a clue for me?
Yes, you can do this in your .rjs.js file
page.replace_html('id_to_replace', :partial => "task_node", :object
=> @task)
I hope this helps
The disadvantage being of course that a large blob of html is encoded
as js and then decoded on the other side.
Why not just scrap the respond_to stuff and have your action be
def search
@project_people
=ProjectPerson.find_person_by_name_fragment(params[:q], params[:p])
render(:partial => 'project_people', :locals => {:pp
=>@project_people })
end
which has worked fine for me in the past.
@Roy: It's not confused by the naming at all. The naming convention
is basically allowing you to render something for the 'js' format
request using the 'erb' rendering strategy. It's your
render :partial=>'blah' that helps it determine that the erb makes
sense, and the format.js that guides it to the 'js' format.
Also, you can simplify your observe_field by using the :submit
option. Submit allows you to provide a dom id that contains some
input fields and it's elements will be serialized and encoded in a
similar manner. The chief advantage will be maintenance:
@Fred: I've done both rendering the partial for a 'replace_html' and
rendered the html and used the :update parameter on the client side.
There does not seem to be much difference in performance. The :update
approach, though, probably makes more sense if you are updating only
one region of the page (as here).
@Fred: I've done both rendering the partial for a 'replace_html' and
rendered the html and used the :update parameter on the client side.
There does not seem to be much difference in performance. The :update
approach, though, probably makes more sense if you are updating only
one region of the page (as here).
I've done both too. It's really only for large amounts of html that it
makes a difference (and it's not something I'd worry about unless it
became a problem). The performance problems were actually mostly
serverside, doing all the escaping on a very long javascript string.