Does using :render => :partial breaks the MVC separation during an ajax call

I am using this function below which updates a div element with a partial in an ajax call.

def publish   render :update do |page|     page.replace_html 'my_div', :partial => 'my_partial'   end end

Does this approach breaks the MVC separation. If Yes, how can we avoid it?

Thanks Deepak Kumar INDIA

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.

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.

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.

Best,

Is the fact that the controller is specifying that a particular div should be updated ('my_div' in this case) a bit non-MVC?

Colin

Colin Law wrote in post #970508:

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.

Colin

Best,

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.