Geek Answers Handbook

Should directing ajax calls communicate with their own separate controller?

Should AJAX calls that are not RESTful:

  • enter the controller that is most suitable for their functionality / view, or
  • along with its separate Ajax controller?

I did 1, but I just read this article (2725 diggs)
http://zygote.egg-co.com/10-dirty-little-web-development-tricks/ (see paragraph 9)
and this guy chooses method 2. But he is a PHP developer.

One of the benefits may be that 2 can clear routes by doing something like "ajax /: action" instead of adding participants to quiet routes.

It seems to be 6.5 of one, half a dozen bakers of another type.

What options do you go with?

+4
source share
2 answers

I prefer the first approach:

  • it is semantically consistent. if the Ajax action includes the XXX resource, you (and other coders) will know where to find things in your application thanks to the Rails conventions.
  • If your application is strong on Ajax (and most of them are currently), you will get an AjaxController behemoth that denies the whole thing is RESTful. The rest of the controllers will be there to provide gracefully degraded actions not related to javascript CRUD.
  • Likewise, testing your Ajax controller will be a little dirty, because you have to configure the scripts - load snap-ins, mocks, etc. for each "ajaxified" resource of your application.
+8
source

Your RESTful controllers probably include new and edit actions, none of which are actually RESTful, they just provide user interfaces for the create and update REST actions. new and edit do not receive a separate NonRestUIController or anything else, they are stored in the appropriate resource controller, keeping your controllers semantically consistent. Similarly, Ajax actions related to a specific set of functionality or a specific resource must remain in the associated controller.

0
source

More articles:


All Articles