Im using a Rails engine as a cms. It all works fine. Im adding devise to this.
My generated devise controllers inherit from Devise::SessionsController. But there are some filters that are run from another controller in the engine that wont run in this case. A lot of the site relies on these filters being run. Of course I could just duplicate them, but thats bad juju.
So my Question is: How can I make one controller run the filters from another? I would prefer not to edit either of the gems.
Multiple inheritance is not supported in Ruby. I think extracting the filters into a module and mixing them in would be the cleanest solution.
See for example:
http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html
There is another option available for Devise: config.parent_controller. It defaults to ApplicationController but can be changed to something else. In my case (a Rails API) I use ApiController. In config/initializers/devise.rb:
Devise.setup do |config|
# ... other configuration options
config.parent_controller = 'ApiController'
end
Related
I recently came across a tricky situation related to rails view helpers.
The situation is like follows-
I am having a controller as Feature1::Feature1.1::Feature1.1.1Controller.
The Feature1.1 also includes other controllers like Feature1.1.2Controller, Feature1.1.3Controller...
So ofcourse related view helpers in folder app/helpers/feature1/feature1.1/...
Now the real problem I am facing is that a few helpers for feature1.1 includes the same method name method1 with related definition.
I was wondering how rails identifies all these helpers as I am noticing that the method1 i.e. being called in a view for the controller feature1.1.1 is using the definition of the method1 i.e. written for the controller feature1.1.2.
So does rails consider all helper modules defined in one folder as one?
In a view feature1/feature1.1/feature1.1.1/index I am making a method call for method1.
I am using rails3
It depends a little bit on your Rails version. With eralier Rails versions, Rails did only include application_helper.rb and <controler_name>_helper.rb.
Additional helper modules can be included via helper :helper_name1, :helper_name2, ... within your controller.
With later Rails verions (4.2.? and up, maybe previous versions too), Rails includes all helpers within your helper folder at once. You can set config.action_controller.include_all_helpers = false within application.rb and you will fall back to the old behaviour.
This makes the helper only available within your views. If you want to use a helper within your controller you still have to include your helper with include XXXHelper.
I did some research and would like to share some additional info.
As per #slowjack2k mentioned, view helpers are included by rails as a default behavior.
But my question was about the situation of same method names across multiple helpers.
I found this article to be useful in this scenario. Though it explains the behavior for Rails 4 but I found it behaves in the same fashion for Rails 3.2.2.
I will summarize the article -
If there will be any conflict in the same names of methods in different helper modules, rails will use method from latter file (alphabetically)
I'm writing a configurable Rails engine. I have an authentication_helper configuration option to define which helper should be called in a before_action in all controllers needing authentication.
The problem is that I don't have access to the parent app's helpers from the engine's controllers. My understanding is that this happens because the engine is isolated.
I have considered using a block instead of a method name, but I'm not sure if that would work, or if I would be able to cleanly access the authorization logic from outside my controllers.
Active Admin, which I have used in the past, has a similar configuration option. I have noticed that their engine is not isolated, so perhaps I'm overrating the importance of engine isolation?
Is there an elegant way to have the benefits of engine isolation while also allowing this kind of customization? Or should I just forego isolation altogether?
EDIT #1
Brad Werth pointed my in the right direction, as this works with a regular controller inheriting from ApplicationController::Base:
module MyBigFancyEngine
class Engine < Rails::Engine
isolate_namespace MyBigFancyEngine
config.to_prepare do
# Make the implementing application's helpers available to the engine.
# This is required for the overriding of engine views and helpers to work correctly.
MyBigFancyEngine::ApplicationController.helper Rails.application.helpers
end
end
end
However, my engine's ApplicationController inherits from RocketPant::Base, which does not provide a helper method. I've tried to use a simple include (which works fine for regular controllers), but that doesn't work either (the controller can't find the helper).
Any ideas?
You can expose the implementing application's helpers available to the engine by including the following code in your engine.rb file:
engine.rb
module MyBigFancyEngine
class Engine < Rails::Engine
isolate_namespace MyBigFancyEngine
config.to_prepare do
# Make the implementing application's helpers available to the engine.
# This is required for the overriding of engine views and helpers to work correctly.
MyBigFancyEngine::ApplicationController.helper Rails.application.helpers
end
end
end
The RailsAdmin Engine is also isolated, but they have the same configuration options as you would like to implement. They have configurable before_filters for both authentication and authorization. Have a look at this.
As far as I can tell, they just subclass the parent controller like this::ApplicationController or instead you can configure one (ref).
For your controller you could just create your own EngineController, that inherits from RocketPant::Base and maybe just create a method there that calls the configured authentication method directly via send on the parent controller.
As the RocketPant::Base Class does not inherit from ApplicationController::Base I guess you have to find some custom way around this and can't go the normal ways for Rails Engines. Maybe you could also try to file an issue to the rocket_pant repo, to add the helper method. As far as I read they soon want to inherit from ApplicationController::Base anyway in 2.0 (ref).
I think you impulse on keeping the isolation is good - because a solution that relies on a method 'just being there' is a pain to debug if s.th. goes wrong in the app using your gem (i.e. typo in method name).
Further if your gem evolves, an some day it won't need the method, in an explicit way it's very convient to give a meainingful error:
You could provide a config method to be called in an initializer:
YourGem.configure do |config|
config.add_callback { MyApp.doIt() }
end
I found this discussion particularly insightful. There are also some interesting ideas in the Rails Engine API under Isolated engine helpers.
The Rails Engine API docs helped me figure out a good solution for url_helpers
You probably moved on by now, but if anyone else needs access to the "parent app" application helpers. You could always just include it explicitly in the application controller in your engine. like so:
include Rails.application.helpers
I am really confused about rails namespaces. I tried to create my own admin namespace so added namespace to routes, this works good. Then i added folder admin into controllers.
Admin::Controller
this is how my controllers in that folder looks.
but here comes the problem. How can i separate Helpers? rails automatically loads all helpers. I disabled that in config but now it wont load it manually like module Admin::ApplicationHelper.
How about next things what needs to be separated? Like i18N, sessions, flashes? Is there a tutorial for this problem? Im using Rails 4. Thanks for advices
As you've noticed rails defaults to including all helpers into all views. You can turn this off by adding
config.application_controller.include_all_helpers = false
This will result in only ApplicationHelper and the controller's helper being included. Adding
helper :foo
To a controller would result in FooHelper being included in addition to the defaults. If there are helpers that should be loaded for all of the admin controllers then add this to their base class. If you need anything more than this then consider using a rails engine (with the isolate_namespaces option turned on)
You only namespace controllers, views, models, and helpers, not everything else you mentioned. If you disabled autoloading helpers you'll have to manually require each one that you need:
require 'admin/admin_helper'
class Admin::Controller < ActionController::Base
... code ...
Same goes for any other helper such as application_helper, etc. Everything else, sessions, flashes, i18n and so on are merely methods from ActionController::Base that all controller's inherit. There's no namespacing these.
Going back to the helpers question: you namespace them the same way you namespace the controllers:
# app/helpers/admin/admin_helper.rb
module Admin::AdminHelper
... code ...
end
And then just require it in your admin controllers if you need to. I'd keep autoloading helpers enabled in order to forego having to require them everywhere.
When you create a namespaced model with rails scaffolding, you get two files. For example, this scaffold:
rails generate model Staff::Location name:string address:string
Generates these files:
/app/models/staff.rb
module Staff
def self.table_name_prefix
"staff_"
end
...
/app/models/staff/location.rb
class Staff::Location < ActiveRecord::Base
...
I am running into problems when in development mode where rails unloads the Staff module and never reloads it. This causes several annoying bugs such as Location not able to access it's table due to the missing table_name_prefix. The problem seems to crop up when I don't access the models directly, such as through a polymorphic relationship.
I can't seem to get the module loaded on a consistent basis. Is this the best practice way to do namespaced models? If it is, what am I missing?
Although I wasn't able to reproduce the problem in Rails 3.2.2, I've run into something like this before. The generic way to hack around this problem in development mode is through an ActionDispatch callback. Add this to config/environments/development.rb:
MyApp::Application.configure do
ActionDispatch::Callbacks.before do
load Rails.root.join('app', 'models', 'staff.rb')
end
end
Anything you do in that block will be executed before each request, so make sure you're only doing it in development mode.† Otherwise, you're going to suffer a performance hit in production.
I logged a message inside the staff.rb file and within the Staff module itself, and both messages appeared in the log for each request.
† I tried using the to_prepare callback, since that seems to be the documented way to execute code before each request only when cache_classes is false. But that only seemed to execute after restarting the application. There's at least one other open Stack Overflow question regarding this, although he's using a slightly different syntax than I used. If you can get to_prepare to work, I'd suggest that instead of before.
About a year later, I have finally found the answer to this question. This answer is specifically for rails 3.1. I am not sure if it is a problem in rails 3.2.
The problem occurs when setting up a model. If scaffolding is used, no helper file is generated. This would normally be in /app/helpers/staff/location_helper.rb. There are two ways to setup this file:
module Staff::LocationHelper
...
end
module Staff
module LocationHelper
...
end
end
In rails 3.1, specifically for helpers, you must use the first solution. You do not have to use it for other modules that use a namespace in other parts of the rails project. In fact, some structures in ruby require the second solution.
If you use the second solution when declaring a helper, in certain cases the Staff module in the helper file will override the module in /app/models/staff.rb. It will silently replace it with the empty Staff module in the file. This does not happen 100% of the time because helpers are not always loaded.
I need to use one of the resourceful controllers plugins - resources_controller/ resource_controller/make_resourceful as I have several polymorphic models and the models have to be either initialized/build depending on the route.
For example:
www.example.com/groups/1/pages
www.example.com/projects/1/pages
where page acts as polymorphic object as both Group and Project have many pages. So I am thinking of using one of the aforementioned plugins to make pages_controller adapt to both routes. All three plugins works fine and differences are just their implementation of recognizing the routes and loading the models based on that.
Now I want to add sub-domain support using Subdomain_fu plugin so the above example would be:
Site1.example.com/groups/1/pages
Site1.example.com/projects/1/pages
Site2.example.com/groups/2/pages
Site2.example.com/projects/2/pages
On looking at all the three plugins, I don't see any way for them to start loading the resources from my subdomain object, as the subdomain is not part of the route. Any advise on what I am trying to accomplish in a dry/restful way?
I don't know how to do that with resources_controller but i was able to pull off the same thing with the inherited_resources plugin.
Here is how i accomplished it:
In my application controller I set up a before_filter to find the subdomain:
def set_subdomain
#subdomain = Subdomain.find_by_url( request.host )
end
Then in my controllers Using inherited resources I set the #subdomain association using the very cool method "begin_of_association_chain"
protected
def begin_of_association_chain
#subdomain
end
Agile web development has great documentation.