I saw what I feel like saying, especially to big mouth blow-hards like yourself.
Ok, does anyone know how to do a page[:div].replace_html on every ajax call, helper or something like that?
Greg Donald wrote:
Why do you prefer RJS to writing JavaScript?
RJS is a template rendering system that also happens to execute JS. I do not prefer one over the other, it's apples and oranges.
OK. Perhaps I should have asked *when* you prefer RJS.
Controller action:
def get_user if request.xhr? @user = User.find( params[:id] ) end end
get_user.rjs:
if @user page.replace_html 'user_tab', :partial => 'user/user_form' page << "$j( '#user_tab' ).fadeIn('slow');" end
Hmm. Why the visual effect here, rather than in the completion handler for the Ajax call? I guess I don't see the point of Rails writing JS, rather than simply handing a JSON packet to the client.
I'll think about this further, though.
How do you keep the generated JavaScript out of your HTML?
Partials.
Wouldn't that still put the JavaScript into your HTML files?
Yup.
Which I don't like to do. Thanks for confirming that this is actually the case.
-- Greg Donald destiney.com | gregdonald.com
Best,
link_to_remote, button_to_remote, periodically_call_remote, submit_to_remote, and remote_form_for all write JS directly into the HTML. Good thing you don't use those.
Hi Marnen,
get_user.rjs:
if @user page.replace_html 'user_tab', :partial => 'user/user_form' page << "$j( '#user_tab' ).fadeIn('slow');" end
Hmm. Why the visual effect here, rather than in the completion handler for the Ajax call?
Because I build more than just toy apps. Sometimes I have complex logic for what effect to show, or what to do when an exception is raised. Sometimes the JS is generated, like:
page << "$j(function(){ $j.notifyBar({ html: '#{ "Enrollment goals updated" }', delay: #{ FLASH_EXPIRE_DELAY }, animationSpeed: 'normal' }); });"
I guess I don't see the point of Rails writing JS,
I agree, you do not.
Greg Donald wrote:
Wouldn't that still put the JavaScript into your HTML files?
Yup.
Which I don't like to do. �Thanks for confirming that this is actually the case.
link_to_remote, button_to_remote, periodically_call_remote, submit_to_remote, and remote_form_for all write JS directly into the HTML. Good thing you don't use those.
Exactly. I'm looking forward to being able to use them in Rails 3, but till then I can't.
-- Greg Donald destiney.com | gregdonald.com
Best,
Greg Donald wrote:
get_user.rjs:
if @user � page.replace_html 'user_tab', :partial => 'user/user_form' � page << "$j( '#user_tab' ).fadeIn('slow');" end
Hmm. �Why the visual effect here, rather than in the completion handler for the Ajax call?
Because I build more than just toy apps.
So do I.
Sometimes I have complex logic for what effect to show, or what to do when an exception is raised. Sometimes the JS is generated, like:
page << "$j(function(){ $j.notifyBar({ html: '#{ "Enrollment goals updated" }', delay: #{ FLASH_EXPIRE_DELAY }, animationSpeed: 'normal' }); });"
I'd consider that problematic application design, but again, I'll think about it further. I'd rather let the client-side JS make this decision.
I guess I don't see the point of Rails writing JS,
I agree, you do not.
-- Greg Donald destiney.com | gregdonald.com
Best,
if in a helper you stick something like
def rjs_flash update_page do |page| ... end end
Then in your templates you can do
page << rjs_flash
You can also do stuff like link_to_function('Foo', rjs_flash) if you use those helpers. (First saw this trick at rails conf europ a few years ago, slides to the talk are here:
Fred
Thanks. I was not sure if there was a totally transparent way to do.
The client side wouldn't yet know if my record was successfully saved to the db or not.
Greg Donald wrote:
link_to_remote, button_to_remote, periodically_call_remote, submit_to_remote, and remote_form_for all write JS directly into the HTML. Good thing you don't use those.
In Rails3 these have all been made unobtrusive.
Yup, but it doesn't mean the old way is suddenly wrong.
Personally I use rjs when it's a good fit, and when it's not I don't - RJS is fine for the simple stuff but sometimes it just doesn't feel like it's worth the effort to massage something into RJS language instead of writing plain javascript - plain old js.erb is easier there. I also don't like writing anything too complicated like this (rjs or js.erb) because I find it awkward to test. It's way simpler to write unit tests that assert that the server side code produces the correct json fragments and then some javascript unit tests to assert that the various possible json payloads are consumed properly.
Greg Donald wrote:
�I'd rather let the client-side JS make this decision.
The client side wouldn't yet know if my record was successfully saved to the db or not.
Then that information could be in the JSON packet, because the server *would* know at the appropriate time. All it would need is one more field.
It seems to me that in most cases, there's something conceptually wrong with sending *behavior* in the way you're describing, rather than *data*. I tend to think that if the client sends an Ajax request for (say) a record to the server, it should get back data for that record, which it can then decide how to render. This would also presumably make it easier to use the same JSON API for both internal Ajax and external Web-service consumers. It also means that JS files can be static, and thus cacheable by the browser.
I like the simplicity of the RJS approach for certain trivial cases (and perhaps for cases where behavior, rather than data, is primarily what the client is requesting), but I'm finding difficulty in seeing how it can scale well or be maintainable. I'll probably play around with it at some point soon and see if I'm missing something that would change my mind.
-- Greg Donald destiney.com | gregdonald.com
Best,
Greg Donald wrote:
Yup, but it doesn't mean the old way is suddenly wrong.
-- Greg Donald destiney.com | gregdonald.com
RJS is difficult to test and especially difficult to debug when things go wrong. I would have to agree with Fred that it's just less complicated to stay away from RJS.
When you need javascript, just write javascript.
And, yes, Marnen has a style of writing that may seem elitist at times, but his arguments serve a purpose. He wants to force a definitive answer if it can exist. I've gotten into many arguments (most positive) with him and in many of those, sometimes I want to yank the strings out of his violin. But, then I calm down and slowly re-read what he's posting and remove any and all tones I might see in the argument.
What I got from Marnen's arguments in this topic were that RJS is more complicated, more often it is clearly unnecessary to use, and it's just better to write .. javascript. All of those points are pretty clear and true.
Greg, some of your own points are pretty clear as well and if you've perfected your RJS templates and they work great in your projects, I see no reason not to reuse them again, if you are happy with them. However, everything changes and RJS is becoming less used. Just keep that in mind.
Thank goodness.. I'll be able to sleep tonight.
