The code sample you provided is very common and many respectful Rails
developers use it.
If we go out of the scope of Rails and start speaking very strictly
about MVC, then probably we can say that it is not actually the
controller’s job to do that type of things. But I think that
render :update has its place in Rails also for a purpose. Until
render :update block gets bigger I think it’s a matter of taste to
have it inside the action or move into the separate rjs file in the
views folder. Your peace of code looks not very different from simple
render :action => ‘action_name’ (I mean looks, but not how it works) -
and we don’t say that it break MVC, that’s why (IMHO) your code
doesn’t break MVC too (it’s too small to break anything :)). But it
can be a good practice to always create a separate rjs file for that
kind of things just in case you need to add more logic.
On 24 December 2010 14:29, Marnen Laibow-Koser [email protected]
wrote:
ivanpoval wrote in post #970446:
The code sample you provided is very common and many respectful Rails
developers use it.
If we go out of the scope of Rails and start speaking very strictly
about MVC, then probably we can say that it is not actually the
controller’s job to do that type of things.
No. It is the controller’s job to trigger render operations. There’s
nothing un-MVC about this at all.
Is the fact that the controller is specifying that a particular div
should be updated (‘my_div’ in this case) a bit non-MVC?
On 24 December 2010 14:29, Marnen Laibow-Koser [email protected]
wrote:
ivanpoval wrote in post #970446:
The code sample you provided is very common and many respectful Rails
developers use it.
If we go out of the scope of Rails and start speaking very strictly
about MVC, then probably we can say that it is not actually the
controller’s job to do that type of things.
No. It is the controller’s job to trigger render operations. There’s
nothing un-MVC about this at all.
Is the fact that the controller is specifying that a particular div
should be updated (‘my_div’ in this case) a bit non-MVC?
Good point! Yes, that might be. So is the fact that the controller
contains literal RJS, but that’s just the way to get it to contain a
render :partial statement.
The code sample you provided is very common and many respectful Rails
developers use it.
If we go out of the scope of Rails and start speaking very strictly
about MVC, then probably we can say that it is not actually the
controller’s job to do that type of things.
No. It is the controller’s job to trigger render operations. There’s
nothing un-MVC about this at all.
But I think that
render :update has its place in Rails also for a purpose.
I don’t like render :update because I don’t like RJS, but it’s a
perfectly appropriate thing for the controller to do if all it’s doing
is calling a partial.
No. It is the controller’s job to trigger render operations. There’s
nothing un-MVC about this at all.
Sure it’s a controller’s job to trigger render operations. But
render :update is a special kind of operation that generates
JavaScript in your action, and sometimes that JavaScript can contain
quite a bit of HTML. Does it 100% sound like a separation of Domain
logic and Presentation? I don’t think so. But we should not be so
critical about this. Render :update construct provides you the same
ability as templates do but it’s inline of the action - thus it’s very
convenient.
It’s more of a question of choosing the right tool to do your job! If
you want to be 100% sure that you don’t break MVC, then put
render :update into the separate rjs template, this way you won’t
waste time thinking if it breaks MVC or not and will focus on your
app. And it will also help you out if you need to put more page
updates into that block and it gets bigger. But I personally love
using render :update since it’s so easy and transparent and fits
perfectly to quickly respond to AJAX call.
Thanks, Ivan Povalyukhin
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.