John Merlino wrote in post #1022569:
Hey all,
This is my understanding of html and browsers. On the server, html is
plain text. When the browser sends request to server to fetch a
document, if the file is not already in html format, perhaps instead
in an rb file, ruby or whatever the server-side language of choice
converts the file to html and sends it to the browser.
No. Suppose you had a .rb file like this:
[1, 2, 3]. each do |num|
puts num * 4
end
How would rails convert that to html? Put <h1> tags around the output?
<div> tags? Use an unordered list: <ul><li></li>...<ul>?
Everything transmitted over http is plain text--it's just that when a
browser sees things like <h1> in the response, it is programmed to
display the text with big, bold letters.
But what if we
have a partial thats not included in the document that is fetched?
Does it remain on the server as plain text and, therefore, is not part
of dom tree and therefore cannot be manipulated by javascript?
If the partial doesn't have anything to do with the document that the
browser requested, then the browser doesn't know the partial even
exists. The browser can only see what is in the response. Likewise, js
doesn't know anything about the partial either.
In
other words, if we try to modify a dom node via javascript that is in
a partial on the server
Impossible. The dom is created by the browser from what's in the
response. If it isn't in the response, it isn't in the dom. Of course,
you can change the current dom with js.
then javascript compiler will
raise an exception of undefined object. Now one technique is to use
ajax, where a user clicks a link, javascript captures event, sends
request to the server via ajax, and ruby handles the request. Now if
the response is to send the object back to the browser,
Just to clarify, plain text is sent back in the response to the js
request. js then interprets the plain text, much like a browser
interprets an <h1> tag in the plain text it receives as a response.
specifically
javascript in plain text, then our rails method would have something
like this: render :text => ret_object.to_json. Now what if that
returned object hash (that utlimately gets converted to json before we
send response back to client) included this: returned_object[:data]
[:view] = render_to_string :partial => '/home/my_table'. Note that
my_table is a partial in home directory.
That is ruby code. js doesn't understand ruby. On the other hand, if
that ruby code executes on the server before the response is sent back,
then something may get added to ret_object, and when ret_object is
converted to json format, whatever was added by the ruby code will be in
the json.
ruby executes on the server, js executes in the browser. js does not
execute ruby code.
When we grab the response
via javascript, then we can stick it anywhere on the existing DOM
tree: $('#my_table .my_content').append(resp.data.view);. Now that
data can be manipulated by javascript. Is this all correct?
Yes. Once js gets a response, the js can do anything it wants with the
response. If the response text is in html format, js can search for
one html element in the text and insert that in the dom, or js can
insert the whole html fragment in the dom.
If the text in the response is in json format, js can extract some data
from the json, insert it in a div tag, and insert the div tag in the
dom.
1) My question is does that partial remain plain text on server until
it is explicitly loaded on the document that was fetched from server.
Everything contained in requests and responses is text, and every file
on the server is text. Once the browser receives some text in html
format, i.e. it has those funny looking tags everywhere, it creates the
dom.
2) What exactly is the point of render_to_string? Why can't we just
use "render"? Or do we need to use render_to_string in order to use
the jquery append method, for example, when appending it to the DOM?
According to railsguide:
... render_to_string. This method takes exactly the same options as
render, but it returns a string instead of sending a response back to
the browser.
So render_to_string does not send a response back to the browser, while
render :text => '<div>hello world</div>" does send a response back to
the browser.