Why Are All Rails Helpers Available to All Views, All the Time? How to Disable This

Why are all Rails helpers available to all views, all the time? Is there a way to disable this?

@George Schreiber's method doesn't work as of Rails 3.1; the code has changed significantly.

However, there's now an even better way to disable this feature in Rails 3.1 (and hopefully later). In your config/application.rb, add this line:

config.action_controller.include_all_helpers = false

This will prevent ApplicationController from loading all of the helpers.

(For anyone who is interested, here's the pull request where the feature was created.)

Are application helper methods available to all views?

Helpers

The bottom line answer is the application_helper is available in all your views.

Rails actually uses helpers all over the place - in everything from the likes of form_for to other built-in Rails methods.

As Rails is basically just a series of classes & modules, the helpers are loaded when your views are rendered, allowing you to call them whenever you need. Controllers are processed much earlier in the stack, and thus you have to explicitly include the helpers you need in them

Important - you don't need to include the ApplicationHelper in your ApplicationController. It should just work

---

Your Issue

There may be several potentialities causing the problem; I have two ideas for you:

1. Is your AgentsController inheriting from ApplicationController?
2. Perhaps your inclusion of ApplicationHelper is causing an issue

Its strange that your AgentsHelper works, and ApplicationHelper does not. One way to explain this would be that Rails will load a helper depending on the controller which is being operated, meaning if you don't inherit from ApplicationController, the ApplicationHelper won't be called.

You'll need to test with this:

#app/controllers/application_controller.rb
Class AgentsController < ApplicationController
   ...
end

Next, you need to get rid of the include ApplicationHelper in your controller. This only makes the helper available for that class (the controller), and will not have any bearing on your view

Having said this, it may be causing a problem with your view loading the ApplicationHelper - meaning you should definitely test removing it from your ApplicationController

---

Method

Finally, your method could be simplified massively, using collection_select:

<%= f.collection_select :agent_id, Agent.all.order(:last), :id, :name_with_initial, prompt: true %>

#app/models/agent.rb
Class Agent < ActiveRecord::Base
   def name_with_initial
       "#{l.first} #{l.last}"
   end
end

Where are Rails helpers available?

In Rails 5 all Helpers are available to all Views and all Controllers, and to nothing else.

http://api.rubyonrails.org/classes/ActionController/Helpers.html

These helpers are available to all templates by default.

By default, each controller will include all helpers.

In Views you can access helpers directly:

module UserHelper
  def fullname(user)
    ...
  end
end

# app/views/items/show.html.erb
...
User: <%= fullname(@user) %>
...

In Controllers you need the #helpers method to access them:

# app/controllers/items_controller.rb
class ItemsController
  def show
    ...
    @user_fullname = helpers.fullname(@user)
    ...
  end
end

You can still make use of helper modules in other classes by includeing them.

# some/other/klass.rb
class Klass
  include UserHelper
end

The old behavior was that all helpers were included in all views and just each helper was included in the matching controller, eg. UserHelper would only be included in UserController.

To return to this behavior you can set config.action_controller.include_all_helpers = false in your config/application.rb file.

Why can private helper methods still be accessed in views?

Helpers are modules that get mixed in to the views. This means that public, protected and private methods in the helper become public, protected and private methods on the views.

I don't think that you can actually hide the helper methods from the view. You'd need to do something like have a helper class which you instantiate in the helper and then delegate calls to that - sounds like it could get messy fast though. :)

Call Rails helper in every view impliedly as first argument

This is what layouts are for. Just call your helper method in your layout and since your views will use that layout so your helper method will also get called up. In your layout file you can do:

%body
  = rails_helper_method
  = yield

Update:

If you look at ajaxify_rails repo, you can call its ajaxify_extra_content method in application_controller and then bind it to ajaxify event. You can do something like this:

def ajaxify_extra_content
  ... your extra html ...
end

and then bind it like this:

$(document).on 'ajaxify:content_inserted', ->
  $('#id_of_some_container_in_view').html $('#ajaxify_content #id_of_some_container_in_view').html()

you can also call your helpers directly like this:

def ajaxify_extra_content
  view_context.your_helper
end

PS I haven't tested it but this should work for you

If helper methods should not interact directly with the database in rails, Why do we put @current_user as helper method?

I will cite recap from coderwall.com

Helpers

Helpers are generic methods which can be use for different kind of objects. I create this kind of helpers link_to_update, big_image, styled_form, etc. Those methods create an html code with a css style or a standard text for example.

Partials

Partials are used to split a big view into smaller logic parts and for larger html code. I can have a partial side_menu, comment_list, header, etc.

Presenters

Presenters is for more complicated queries with two or more models. I have some partials like @page_presenter.page_in_category(ruby_category) or @user_presenter.user_following(an_article).

Decorators

Decorators should act with only one model and shouldn't take parameters (if it's possible). I can do something like this user.full_name, page.big_title or category.permalink. I use the gem Draper.

So, essentially decorators are things which take data from single model object and manipulate it in some way (for example, squishing first_name + last_name into full_name and such things).

current_user, on the other hand, definitely doesn't belong to the decorators because it doesn't deal with manipulating any object's data – it actually finds the object you need (using session/cookies data for that).

I'd say its place is in ApplicationController (or one of its specific descendants which you can build, say, AuthenticatedController or such), because you often need to know current_user in a controller itself (not its view), and it takes unneeded efforts to make your view helper method available for controller.

Helpers in Rails 4

Because all helpers are included in all controllers, by default. The separate files are really just for logical separation in this scenario. You can change that behaviour though:

By default, each controller will include all helpers.

In previous versions of Rails the controller will include a helper
whose name matches that of the controller, e.g., MyController will
automatically include MyHelper. To return old behavior set
config.action_controller.include_all_helpers to false.

http://api.rubyonrails.org/classes/ActionController/Helpers.html

Ruby on Rails: Global Helper method for all controllers

You can include ApplicationHelper in your controllers (or base ApplicationController) to make the helper methods available.

You can also include the following line in your ApplicationController to include all helpers:

helper :all

how can i use a helper in different views

In your application_helper.rb:

module ApplicationHelper
  include Admin::MyHelper
end

This will import those helper methods into the ApplicationHelper, thus making them available in your views. You could do this in any of your helpers really.

---

Related Topics