What's the Difference Between Controllers and Actions in Ruby on Rails

What's the difference between controllers and actions in ruby on rails?

Controllers are just Ruby Class files which have a series of instance methods inside


Basic Explanation

Rails controllers are basically files where actions (methods) are kept

Each time you access a Rails app, you're sending a request to the system. The various technologies inside Rails route that request to a certain action, where your code can use the passed data to perform some sort of action (hence the name). The actions are kept inside controllers to give the application structure

So if you access http://yourapp.com/users/new, it tells Rails to load the new method in the users controller. You can have as many actions in the controllers as you want, but you have to tell the Rails routes system they are there, otherwise they won't be accessible


Proper Explanation

Rails Controllers are just Ruby Classes, storing a series of actions

The "actions" (instance methods) work on passed data (params) to create objects that can either be passed to the model, or used inside other methods

Whenever you send a request to Rails (access a URL), it first uses the ActionDispatch middleware to send your request to the correct Class (controller) instance method (action), and then your code does something with that data

Your job as a dev is to connect the right controllers with the right models, presenting the right data the user at the right time

Action and method in Rails controller

Action is also a method but it has a corresponding route, you can hit an action by using it's route but you can't call method an action if it doesn't have any route associated with it.

e.g. In rails new, index, create, show, update, delete and edit are default actions, because all these methods have routes associated with them. But if you define a method in the controller which is called by an action but it doesn't have any route associated with it then its a method but not an action.

What is the difference between ActionController::API and ApplicationController

From the docs (which are the first hit on the googlies)...

API Controller is a lightweight version of ActionController::Base, created for applications that don't require all functionalities that a complete Rails controller provides, allowing you to create controllers with just the features that you need for API only applications.

An API Controller is different from a normal controller in the sense that by default it doesn't include a number of features that are usually required by browser access only: layouts and templates rendering, cookies, sessions, flash, assets, and so on. This makes the entire controller stack thinner, suitable for API applications. It doesn't mean you won't have such features if you need them: they're all available for you to include in your application, they're just not part of the default API controller stack.

Difference between actions and filters in rails

OK, so this is how I see things:

1: An action is a method of a controller to which you can route to. For example, your user creation page might be routed to UsersController#new - new is the action in this route.

2: Filters run in respect to controller actions - before, after or around them. These methods can halt the action processing by redirecting or set up common data to every action in the controller.
For example:

before_action :require_logged_out, only: [:new]
def require_logged_out
redirect_to user_path(current_user) if logged_in?
end

So here, require_logged_out is a filter which runs before the new action of the users controller.

3: Lastly I'll mention that in Rails 3.x *_action filters have been defined via *_filter. for example, you'd set a before_filter and not a before_action.

I think that should wrap things up for you regarding actions and filters in rails.

Different behavior for the same controller action in Rails

if the 2 variations are significantly different and must be invoked from the same controller, you could use an around_filter and dispatch the controller.action_name to one of 2 classes that inherit from the same base.

if the 2 variations aren't so different that they require forking, ifs should be fine...

for the dispatching, it could be just a generic class that inherits from a base class. you can have a switch in your filter that creates the right object based on the role, then finally send(“#{action}”) on the object. i would only do that if the variations are so different that they merit 2 derived classes.

now aside from generic classes, you could also use the handy Components w/the render_component method. in most cases the overhead of dispatching to a component controller would be rather negligible. (this is kind of like a server-side transfer (Server.Transfer) in .net.)

what determines controller action ruby rails

  1. Yes. and #home is the "action" in PagesController
  2. You get a uninitialized constant PagesController error

So, your controllers should always be in the form NameController defined in name_controller.rb, and actions as public methods in NameController.

difference between resource and controller generators

You should call

rails g controller user index create new destroy show

instead of

rails g controller users index create new destroy show

in order to get resources :users to give you the helpers you want.

The latter causes Rails to assume that users is a singular object, and that resources :users should create what is called a singular resource:

http://guides.rubyonrails.org/routing.html#singular-resources

as a result, user_path is undefined, whereas users_path is defined.

Does it belong to controller or model?

A simple test (of whether it's a controller / model action) is to look at what the action is meant to do - does it work with data or params?

Rails models are meant to be "locked away" from much of the higher-level logic in your application; it's meant to provide a base-level set of actions to manipulate the data being inserted into your db; anything requiring request-level data should be handled in the controller.

Sample Image

As such...

redirect_to store_settings_store_path(id: current_store.id)

... because you're manipulating the flow of your app, your logic should stay in the controller.

If you weren't redirecting (IE were only manipulating data), you'd be able to put this functionality into a before_create callback in your model.



Related Topics



Leave a reply



Submit