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
- Yes. and
#home
is the "action" in PagesController - 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.
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
Can't Use Compass After Installing It
Instance and Class Variables in Rails Controller
Best Way to Generate Order Numbers for an Online Store
Suitability of Rails, Padrino, and Sinatra for Building a Prepaid Mobile Service
Best Practice About Empty Belongs_To Association
How to Generate a Random Date in Ruby
Error When Starting Rails Server: Warning: Insecure World Writable Dir /Usr in Path, Mode 040777
Why Should I Use Rspec or Shoulda with Rails
What Are the Reserved Words Begin or End Used for in Ruby
Rails Belongs_To Association (With :Class_Name) Returns Nil
Why Are Constants from Extended Module Not Available in Class Methods Declared with Self