Question

Should AJAX calls that are not RESTful be:

  1. put in the controller that most suits their functionality/view, or
  2. bundled together into their own separate 'Ajax' controller?

I've been doing 1, but I've just read this (2725 diggs) article
http://zygote.egg-co.com/10-dirty-little-web-development-tricks/ (see point 9)
and this chap opts for method 2. But he is a PHP developer though.

One benefit could be that 2 might clean up the routes by doing something like 'ajax/:action' instead of adding members to restful routes.

It seems like a 6.5 of one, half a baker's dozen of the other type thing.

Which option do you go for?

Was it helpful?

Solution

I prefer the first approach:

  1. it's semantically consistent. if an Ajax action involves resource XXX, you (and other coders) will know where to find things in your application, thanks to Rails conventions.
  2. if your application is heavy on Ajax (and nowadays most of them are), you will end up with a behemoth AjaxController that negates the whole RESTful thing. The rest of your controllers will be there just to provide gracefully degraded non-javascript CRUD actions.
  3. Similarly, testing your Ajax controller will tend to be somewhat messy because you will have to set up scenarios --load fixtures, mocks, etc. for each and every "ajaxified" resource of your app.

OTHER TIPS

Your "RESTful" controllers probably include new and edit actions, neither of which are actually RESTful, they just provide user interfaces for the create and update REST actions. new and edit don't get a separate NonRestUIController or something, they are kept in their associated resource's controller, keeping your controllers semantically consistent. Similarly, Ajax actions that relate to a certain set of functionality or a certain resource should stay in the associated controller.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top