Будьте очень осторожны, следуя советам, изложенным в посте Чака, если вы делаете это в Rails 3.2.1.Казалось бы, такой подход не является безопасным способом включения хелпера link_to в классы без представления в Rails 3.2.1.Существует более безопасный способ (который работает для нас в любом случае), описанный ниже.
Когда мы использовали подход, описанный в сообщении Чака в одном из наших классов, он оказался очень неприятным и трудным для отладки последствий.Это привело к возникновению побочных эффектов / ошибок, которые возникали только в очень специфических (и редких) обстоятельствах.
Проблема, насколько мы можем судить, заключается в том, что эта строка:
ActionView::Base.send(:include, Rails.application.routes.url_helpers)
Говорит ActionView::Base
включить Rails.application.routes.url_helpers
, что ActionView::Base
, по-видимому, уже само по себе.Включение url_helpers
во второй раз, по-видимому, вызывает повторную инициализацию состояния маршрутов (@_routes в классах, которые включают модуль ActionDispatch :: Routing :: UrlFor).
Это, по-видимому, приводит кслучайные и необъяснимые «неопределенные методы« url_for »для nil: NilClass» исключения в представлениях, которые пытаются вызвать, прямо или косвенно, метод url_for после того, как ActionView::Base
включило url_helpers
во второй раз.
Решение, которое сработало для нас, заключалось в том, чтобы вместо ActionView::Base
снова включить url_helpers
, просто включить модуль UrlHelper
самостоятельно, где бы он вам ни понадобился.
Тогда, когда вам нужноЧтобы использовать link_to и иметь доступ к пути, вы можете просто сделать это (при условии, что login_path действителен для вашего приложения):
include ActionView::Helpers::UrlHelper
...
link = link_to('here', Rails.application.routes.url_helpers.login_path)
Нам потребовалось очень много времени и много царапин, чтобы отследитьошибки, вызванные двойным включением, и я просто хотел предупредить других, чтобы они были осторожны при настройке поведения базовых классов Rails.