My shopping site has a header that's common across all pages.
I have added a shopping cart icon in the header, with a number that updates based on the contents in the current cart.
Because this icon requires a definition for current_cart, I now need to add this to every controller action. Is this unwise/unsafe? I'm new to rails, and don't quite understand the security repercussions of adding methods to applications.rb
Also, is the best way to do this to add this once to application_controller.rb, or to add it separately to each relevant controller action?
Thanks in advance for the feedback!
Having DRY in mind it's definitely better to add this method once, one level up in yours controller inheritance tree. If all controllers need that method then application_controller.rb is a good place. If just some of them then you may consider to create controller which inherits from ApplicationController, store that method in it, and all controllers that requiers that method should inherits form it.
All of your controllers inherit from the application controller. This means that any method you define in the application controller is available in all of your other controllers.
Related
I'm building a ruby on rails app and I have rather big controllers.
Now I have the same actions to be done on a create action and a delete action so I was wandering if it's possible to make this DRY. Or is this only possible with views?
There are a few ways you can achieve this:
Move all model related code to your models and call model actions on models in your controller. This is a great way to clean up your controller especially if you are querying the model for generic things.
Create private actions in your controller to reduce duplication of code.
You can create methods inside a module and import the module into your controller. This should reduce the size of your controller as well as making it DRY (you could even reuse that module in different controllers).
module MyModule
def my_method
end
end
# in controller
include MyModule
You can only create partials in view.
Code repeatation in controller can be made DRY by writing the similar part of code as a method in Model and calling it in as many actions in controller.
In rails4 had a folder which called concern, you can use concern to split your code in controller.
You can refer about concern at: concern
I have a GridDataController class that handles all of my data requests from my jqGrids.
I think my application would be easier to maintain if I busted that class apart, put the relevent actions in their respective controllers, keep the grid specific functions in a base controller class and then inherit from that class when I need to retrieve grid data in my controllers.
It doesn't seem right for the Base Controller class to reside in the Controllers folder as I do not want any of it's actions to be called.
Is there a convention for this?
No conventions. It would be easier for everybody though if you put it under Controllers, since its a controller, want it or not :). However, you can put it anywhere and refer to it inside your controllers by using and by inheriting from it (if that's what you want to do).
If you don't want its actions to be called, declare it appropriately as abstract class ...
So, no right answer to your question, but before putting it anywhere, thing twice and change your mind and put it back into Controllers :)
If I have a methods that I want to use in several controllers, to keep my code DRY.
What is the rails way of doing this?
If you want to have your code reusable, I think application_controller is the best place to do so. Create any method you think it's reusable in multiple controllers in application_controller and call them in any controller you want.
My application_helper.rb is getting pretty big. In my defense, it contains only HTML-generating methods, and none of those methods perform any sort of business logic. None of the methods are specific to any page or controller, and most are unrelated to each other.
What's the typical solution to this problem? Suck it up? Create additional *_helper.rb files to absorb some of application_helper's methods?
Usually we have helpers for controllers (one helper per controller, were you would place helper methods used only on that controller's templates) and you can also create helpers based on your own organization.
If you have many methods related to polls, you could create a PollsHelper and place all methods in there, even if there isn't a controller called PollsController. Also, Rails always loads all helpers and includes them in your views, so you can name them whatever you like (as long as they're inside the helpers folder and they end with _helper).
Typically I organise by type - e.g. button_and_link_helpers, conditional_helpers etc. I just create them as modules and include them in the controllers that need them.
This has the benefit of not loading loads of unused functions for every view
I try to be very good about keeping my view code and my controller code separate, but occasionally I run into situations where I need to use the same function in the controller and in the views. Where should I put this function so that I can access it from both the controller and the view?
You can put it in a controller and make it available as a helper. If you need it to be available between multiple controllers and their views put in the application controller or other inherited controller:
helper_method :shared_function
According to your situation, for example if the function return a standard Variable value that don't require any controls, you can call it directly from the view, on the contrary, if you have a function that return for example an array that requires controls it's judicious to call it from the the model before you show what you want on the view.
I actually think a module is the best way to share code amongst controllers. Helpers are good if you want to share code amongst views. Helpers are basically glorified modules, so if you don't need view level access, I suggest placing a module in your lib folder.
If the code is really a set of utilities that doesn't need access to object state, I would consider putting it in a module to be called separately.
If the code needs state and is used in a subset of all controllers that are not very closely related, put it in a module and include it in necessary controllers.