In my application, I have an user model/controller. An user can have multiple videos, images and blog items. User, and the items can have comments. So I've got the following controllers
user
user/comments
user/picture
user/picture/comments
user/video
user/video/comments
user/blog
user/blog/comments
The problem is, all the comments controllers are almost identical, and the code is becoming hard to manage. Now I'd like to specify a central place, e.g. a app-level CommentsController, which would have the methods to be called from sub-controllers.
What is the best way to do that?
How would for example the following code look after such a change:
class User::Picture::CommentsController < ApplicationController
def delete_all
#user = User.find(params[:user_id])
#picture = #user.pictures.find(params[:picture_id])
if #picture.has_access(current_user)
#picture.comments.destroy_all
redirect_to :back, :notice=>t(:actionsuccesful)
else
redirect_to :back, :alert=>t(:accessdenied)
end
end
end
The #user && #picture initializations are same among different methods (destroy, delete_all, create, index). Could they be moved into a before_filter which would be a sub-controller specific? And then, delete_all would be implemented in the CommentsController?
If the code is that generic, two options:
1) a module including shared methods
Example:
module CommentsActions
# actions, methods
end
class User::Picture::CommentsController <ApplicationController
include CommentsActions
#your additional actions
end
2) subclassing comment controllers from one controller
Example:
class CommentsController < ApplicationController
# actions, methods, filters etc...
end
class User::Picture::CommentsController < CommentsController
#your additional actions
end
Related
Example code:
#model
class Profile < AR:Base
has_many :projects
end
#controller
class ProfilesController < AC
def show
#user = Profile.find(params[:id])
end
end
#view
#profile.projects.each do |project|
= render something
end
Any user can view any profile, but projects should be filtered by visibility (like public/private projects).
I'm concerning to add one more ivar because it violates Sandi Metz's rule
Controllers can instantiate only one object. Therefore, views can only
know about one instance variable and views should only send messages
to that object (#object.collaborator.value is not allowed).
The only way I see it now is to introduce another class (facade) to do this things, like:
class ProfilePresenter
def initialize(profile, current_user)
#profile = profile
#current_user
end
def visible_profiles
ProjectPolicy::Scope.new(current_user, profile.projects).resolve
end
end
Am I missing something?
How would one achieve it (resolving association scopes) using Pundit?
In case we will need pagination for projects within profile view - what approach to choose?
I have two models:
Student
Classroom
Both of them have an action that does the same exact thing: it shows a report of daily activity. That is:
/students/1
/classrooms/1
Grabs activity for the model in question and displays it on the page.
In an attempt to dry this up, I created a ReportsController which extracts all the common logic of building a report.
If I leave the routes like this:
/students/1/report
/classrooms/1/report
Then I can have the ReportsController#show action look for params for :student_id or :classroom_id to determine which model type it is dealing with (for purposes of querying the database and rendering the correct view).
But I would prefer the URLs to be cleaner, so I also changed my routes.rb file to pass the show action for these models to the reports#show controller action:
resources :students, :classrooms do
member do
get :show, to: 'reports#show'
end
end
This works, but I can no longer depend on params to identify which model to work with and which view to render.
Question: should I parse request.fullpath for the model? Or is there a better way to make a shared controller understand which model it is working with?
Routing both show methods to the same controller method for code reuse is somewhat like banging a nail in with a dumptruck.
Even if you can find the resource by looking at the request url you would start splitting the ResortsController into a bunch of ifs and switches even before you got off the ground.
One solution is to add the common action in a module:
module Reporting
extend ActiveSupport::Concern
def show
# the Student or Classroom should be available as #resource
render 'reports/show'
end
included do
before_action :find_resource, only: [:show]
end
private
def find_resource
model = self.try(:resource_class) || guess_resource_class
#resource = model.find(params[:id])
end
# This guesses the name of the resource based on the controller name.
def guess_resource_class
self.class.name[0..-11].singularize.constantize
end
end
class StudentController < ApplicationController
include Reporting
end
# Example where resource name cannot be deduced from controller
class PupilController < ApplicationController
include Reporting
private
def resource_class
Student
end
end
self.class.name[0..-11].singularize.constantize is basically how Rails uses convention over configuration to load a User automatically in your UsersController even without any code.
But the most important key to DRY controllers is to keep your controllers skinny. Most functionality can either be moved into the model layer or delegated out to service objects.
I would put the common logic in the Event Model:
#Event Model
class Event < ...
def self.your_event_method
#self here will be either student.events or classroom.events
#depending on which controller called it
end
end
class StudentsController < ...
...
def show
student = Student.find(params[:id])
student.events.your_event_method
end
end
class ClassroomsController < ...
...
def show
classroom = Classroom(params[:id])
classroom.events.your_event_method
end
end
The code below shows two controllers that have before_filters added in different orders. As a result, the controllers have different behavior.
When current_user is nil (logged out):
FooController -> redirects to login_path
BarController -> redirects to root_path
You could, of course, combine the two methods and make them smarter to make this specific example go away -- but that is missing the point of this question.
The issue at hand is that, in ActionController, the order that filters get added is relevant. (You could also argue that that implementation isn't the greatest, but that's how it is -- so let's move on)
Since that's how ActionController works, I would like to test that behavior. However, it isn't necessary to test the results of the before filters on each individual action (not DRY). As far as I can figure, what's actually important is the resulting order of the filter chain on each action.
The only thing that before_filter :require_user actually does is inject an item into the callback chain - and that's all I should have to test for in my subclasses - that an additional item has been added to the chain. I don't need to test the effect that require_user has on my actions - they can, and should, be stubbed.
That all said, here's the money question: Is there a public API that returns what methods are in a given controller and action's filter chain? This should include before, after and around filters in their appropriate order.
class ApplicationController < ActionController::Base
def require_user
unless current_user
redirect_to login_path and return
end
end
def require_admin
unless current_user.try(:admin?)
redirect_to root_path and return
end
end
end
class FooController < ApplicationController
before_filter :require_user
before_filter :require_admin
end
class BarController < ApplicationController
# reverse the order of the filters
before_filter :require_admin
before_filter :require_user
end
You can access the list of filters via the _process_action_callbacks class method. For a list of filters, you can:
FooController._process_action_callbacks.collect &:filter
I have several controllers that require a correct user for their edit/update/delete actions. What is the Rails-way to accomplish the following:
Currently, in each controller I have the following code:
class FooController < ApplicationController
before_filter :correct_user, :only => [:edit, :update, :destroy]
# normal controller code
private
def correct_user
#foo = Foo.find params[:id]
redirect_to some_path unless current_user == #foo.user
end
end
I have similar code in 3 controllers. I started to bring it out to a helper like this:
module ApplicationHelper
def correct_user( object, path )
if object.respond_to? :user
redirect_to path unless object.user == current_user
end
end
But I'm wondering if this is a good way to do it. What's the accepted way to solve this?
Thank you
EDIT
The correct user check here is because I want to make sure it's only the author who can make edits/deltes to each of the objects.
To clarify, the objects would be things like Questions and Posts. I don't want to use something like CanCan as it's overkill for something simple like this.
I really like using RyanB's CanCan, which allows you to both restrict access to actions based on the user, and centralize such authorization into basically a single file.
CanCan on GitHub: https://github.com/ryanb/cancan
Screencast explaining how to setup/use it: http://railscasts.com/episodes/192-authorization-with-cancan
EDIT
No problem. I hear you on CanCan - it takes a little while to get up and running on it, but it's designed to do exactly what you're asking - per object authorization.
Alternative:
Another way to do this is move your authoriship/current_user check to the ApplicationController class, from which all of your other Controllers inherit (so they will get that code through inheritance - and you don't need to write the same code in multiple Controllers), and it would look something like...
class ApplicationController < ActionController::Base
...
helper_method :correct_user
private
def correct_user( object, path )
redirect_to path unless object.user == current_user
end
end
You should do the following :
def edit
#foo = current_user.foos.find(params[:id])
end
This way, only if the current user is the owner of the Foo he will be able to see it.
I'm struggling a bit to find the right place for a helper method. The method basicly 'inspects' a User-model object and should return some information about the 'progress' of the user, eg. "You need to add pictures", "Fill out your address" or "Add your e-mail-adress". None of the conditions I'm checking for are required, it's just like a "This is your profile completeness"-functionality as seen on LinkedIn etc.
Each of these 'actions' have a URL, where the user can complete the action, eg. a URL to the page where they can upload a profile photo if that is missing.
Since I need access to my named routes helpers (eg. new_user_image_path) I'm having a hard time figuring out the Rails-way of structuring the code.
I'd like to return an object with a DSL like this:
class UserCompleteness
def initialize(user)
end
def actions
# Returns an array of actions to be completed
end
def percent
# Returns a 'profile completeness' percentage
end
end
And user it with something like: #completeness = user_completeness(current_user)
However, if I'm adding this to my application_helper I don't have access to my named routes helpers. Same goes if I add it to my User-model.
Where should I place this kind of helper method?
This is a similar problem to that of Mailers. They are models, and should not cross the MVC boundaries, but need to generate views. Try this:
class UserCompleteness
include ActionController::UrlWriter
def initialize(user)
end
def actions
# Returns an array of actions to be completed
new_user_image_path(user)
end
def percent
# Returns a 'profile completeness' percentage
end
end
But be aware you are breaking MVC encapsulation, which might make testing more difficult. If you can get away with some methods in the users helper instead of a class that might be better.
From the little i got your question i think you want a method which you can used in Controller as well as Views.
To Accomplish this simple add method in application_controller.rb and named it hepler_method
Example:-
class ApplicationController < ActionController::Base
helper_method :current_user
def current_user
#current_user ||= User.find_by_id(session[:user])
end
end
you can use method current_user in both Controller as well as views