repeated methods in rjs

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:
http://www.slideshare.net/RubyOnRails_dude/marcel-molina-jr-presentation

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.