Lets say that we have a rails app which has a sidebar on every page that shows some data, like post archives, post categories etc. Which is the best way to share the same data on each of our controllers?
Iguess the most easy fix is to use the same before_actions on each controller, but this doesn't DRY up much our code, or maybe move all these into a parent class/cotrnoller that all controllers will inhert from, but is there a better way of doing this?
Simple Solution:
Normally, I just put these into application_controller.rb as a before_action.
Example
# app/controllers/application_controller.rb
before_action :set_sidebar_resources
# ...
private
def set_sidebar_resources
#sidebar_archives = Archive.all
#sidebar_categories = Category.all
end
Modular Solution:
Simple solution above works great until you define more and more methods and other global controller logic into ApplicationController, and then the file becomes too big to manage. The following is a less conventional approach favouring more of manageability rather than simplicity.
Example
# app/controllers/application_controller.rb
include WithSidebar
# app/controllers/concerns/with_sidebar.rb
module WithSidebar
extend ActiveModel::Concern
included do
before_action :set_sidebar_resources
private
def set_sidebar_resources
#sidebar_archives = Archive.all
#sidebar_categories = Category.all
end
end
end
Rails controllers inherit from application controller.
ex.
class ClientsController < ApplicationController
You could add before_actoion to ApplicationController that pulls the data you want into #variable and then use that variable in other controllers.
Just don't over-do it and keep your controllers skinny :)
Related
Current I have three controllers that uses the exact same authorize_journey method (located in the controllers). Each controller also calls the exact same before_filter :authorize_journey. What is the best way to reduce this kind of redundancy through best-practice?
Also, how can I, if possible, stick to the fat-model-skinny-controller practice?
If the authorize_journey methods are all identical, then you can move a copy to '~/app/controllers/application_controller.rb' and remove it from all the individual controllers.
The before_filters can all remain as they are.
Of course, if the methods are not identical, you may require some refactoring to generalize it further. If you post the code, we can comment further.
You can always use it in the application_controller.rb.
Move the authorize_journey method to application_controller.
Say if you have 4 controllers and you need the before_filter in 3 controller. Then you can define the before_filter :authorize_journey in the the application_controller and use:
skip_before_filter :authorize_journey
in the 4th controller where you don't want the before_filter
I would suggest adding the method to a concern and include them in the controllers that requires the authorize_journey before_filter.
Code for concern will be:
# controllers/concerns/authorize_journery.rb
module AuthorizeJourney
extend ActiveSupport::Concern
included do
before_filter :authorize_journey
end
protected
def authorize_journey
# Code goes here
end
end
Now in the controllers, include the AuthorizeJourney module.
# controllers/examples_controller.rb
class ExamplesController < ApplicationController
include AuthorizeJourney
# Code goes here
end
I have a basic model called Page and have many STI models based on Page such as
Drawing
Article
Story
etc...
I have separate controller and view for each of these STI models because I needed to customized the view layer based on the model type and have different logic for controller and hence separate controllers. However, I need the author field of all models to be set to current user. How do I do this in a single place?
For example, if I use before_action on Page controller and set the author, it affects the #page instance variable whereas my DrawingsController is using #drawing so it wont save the author of my #drawing unless I repeat the same code in DrawingsController.
Edit:
My controller hierarchy is
DrawingsController < PagesController
PagesController < ApplicationController
Both PagesController and DrawingsController have all the 7 restful actions. However, the actions on PagesController doesn't serve any purpose as I dont want any of my users to create Pages. I only want them to create the inherited STI classes like Drawings.
you could do this using some convention and meta programming in your controller hierarchy:
def add_author
model = instance_variable_get(:"##{controller_name.singularize}")
model.author = current_user
end
I'll be honest, I make no guarantees about the "best-practice"-ness of this answer, but I'll propose it anyways in case it helps to some degree. Also note that after rethinking the problem, I realized my first suggested solution in the comments was wrong, and the second is also not quite right either. So I'm posting a modified version of the second suggestion only:
Short answer: Let the PagesController handle most of the work, and delegate only to the subcontroller for model-specific things if needed. As phoet said, you can use a bit of meta programming (in a different way) to accomplish this.
class PagesController < ApplicationController
# pages controller stuff here
def create
#page = controller_name.classify.constantize.new(params[:page_params]) # I love Rails, don't you?
#page.author = current_user
handle_additional_create_actions
# For completeness of this example...
if #page.save
# render / redirect on success
else
# render errors
end
end
protected
# This method should be overwritten by sub controllers if needed
# Also, name this whatever you like, this is merely a verbose example for illustration purposes
def handle_additional_create_actions
# in the pages controller, this method does nothing
end
end
And, if there are additional things that need to be done by the model-specific controller:
class DrawingsController < PagesController
# drawing controller stuff here
protected
def handle_additional_create_actions
#page.some_other_field = some_other_data
end
end
A quick note: Note that in my suggestion, you're eliminating the model-specific variable names, meaning we don't have an #drawing and an #article, etc, anymore. Your models are all, essentially, types of Page objects, and so we're going to call it by its general name as a convention. That way, when you ask the DrawingsController to do something specific for the Drawing class, it knows that instance can be accessed via our generically named #page object.
So ultimately, the PagesController does the heavy lifting, regardless of which concrete model type you're dealing with. That way, only general page stuff is found in the pages controller, and drawing, article or story-specific stuff is found in their respective concrete controllers.
This is going to sound strange, but hear me out...I need to be able to make the equivalent of a POST request to one of my other controllers. The SimpleController is basically a simplified version of a more verbose controller. How can I do this appropriately?
class VerboseController < ApplicationController
def create
# lots of required params
end
end
class SimpleController < ApplicationController
def create
# prepare the params required for VerboseController.create
# now call the VerboseController.create with the new params
end
end
Maybe I am over-thinking this, but I don't know how to do this.
Inter-controller communication in a Rails app (or any web app following the same model-adapter-view pattern for that matter) is something you should actively avoid. When you are tempted to do so consider it a sign that you are fighting the patterns and framework your app is built on and that you are relying on logic has been implemented at the wrong layer of your application.
As #ismaelga suggested in a comment; both controllers should invoke some common component to handle this shared behavior and keep your controllers "skinny". In Rails that's often a method on a model object, especially for the sort of creation behavior you seem to be worried about in this case.
You shouldn't be doing this. Are you creating a model? Then having two class methods on the model would be much better. It also separates the code much better. Then you can use the methods not only in controllers but also background jobs (etc.) in the future.
For example if you're creating a Person:
class VerboseController < ApplicationController
def create
Person.verbose_create(params)
end
end
class SimpleController < ApplicationController
def create
Person.simple_create(params)
end
end
Then in the Person-model you could go like this:
class Person
def self.verbose_create(options)
# ... do the creating stuff here
end
def self.simple_create(options)
# Prepare the options as you were trying to do in the controller...
prepared_options = options.merge(some: "option")
# ... and pass them to the verbose_create method
verbose_create(prepared_options)
end
end
I hope this can help a little. :-)
I'm developing a classified ads site which will have display same sidebar on almost every page. A list of categories which are fetched from the database.
I find myself duplicating the same code in each controller to do this. i.e.
before_filter :load_categories
Where :load_categories performs a simple
private
def load_categories
#categories = Category.all
end
Not very dry when you have a lot of controllers.
Is there a way for my to dry this process up?
You could put this on ApplicationController, but honestly I recommend against that. ApplicationController tends to become a big bloated blob over time, accumulating utility functions that are really not related, definitely not SRP. It can get ugly.
What I've done to keep things DRY is to create a parent controller that related controllers can inherit from. Put your before_filter on that and have the related category-using controllers inherit from it.
Maybe:
class MainPagesController < ApplicationController
before_filter :load_categories
private
def load_categories
#categories = Category.all
end
end
class SomeController < MainPagesController
# etc.
end
If your app is small-ish, won't grow significantly over time, and you truly do load #categories on almost all of your pages, then putting it on ApplicationController might make sense. But I tend to err on the side of over-DRYing my code. Very small classes that have siloed functionality is never a bad thing.
You can put def load_categories definition in ApplicationController and it will be accessible from every controller in your application.
You can put before_filter :load_categories in ApplicationController too, if you want it to be executed for every controller.
Although, frankly, it doesn't seem like a huge case of code redundancy to me. In fact, simply calling Category.all in every action/view where you need categories might be simpler. Since results are cached, there's no performance penalty.
You can put your method in ApplicationController and your before_filter in too.
If you want avoid it in one specific controller you can skip it after
A newbie question:
I have a partial that I'm loading on a website on different pages.
That partial needs some data, so in the controller of the parent view I do the query:
#properties = Property.find(:all)
I pass the query results to the partial in the view using :locals
Now, I would like to render the same partial from another view. This view has a different controller. Do I have to repeat the query in that controller also? Or can I have a separate controller for partials I use one more places in the website. In this last case, how do I indicate which controller to use in the view when I put the render command?
Or should I use somethink different than partials for this kind of use?
Kind regards,
Michael
How i would solve this, is to define a new file inside your lib folder, with a meaningful name. For now i will just use does_as_shared.rb:
module DoesAsShared
def setup_shared_data
#shared_data = ...do something useful here ...
end
end
and then inside your controllers that need that code you write:
class ThingsController < ApplicationController
include DoesAsShared
def index
setup_shared_data
.. and do some more stuff ...
end
end
The advantage of this code is that the shared code is limited to those controllers that really need it. And at the same time it is pretty readable: the include statement, given that the name is chosen well, clearly indicates what functionality is included.
You don't need to copy the code to set up the partial's data, but you would need to hoist it into a controller that your two controllers inherit from. Normally, this would be your ApplicationController. Define a method in there that loads the data you need. For example:
class ApplicationController < ActionController::Base
# ... your code ...
protected
def load_partial_data
#properties = Property.find(:all)
end
end
Now to actually call this method you have two options:
If all your controllers need this data, add a before_filter to your ApplicationController like before_filter :load_partial_data
Otherwise, add the before_filter to just the controllers that actually need to load the data.
I hope this helps.