Retain ActionPack dependency on ActionView

This commit is contained in:
Łukasz Strzałkowski 2013-12-05 00:17:39 +01:00
parent 501acab943
commit d8888b94b3
6 changed files with 5 additions and 22 deletions

@ -15,9 +15,6 @@ def mail_with_i18n_subject(recipient)
end
end
# Emulate AV railtie
ActionController::Base.superclass.send(:include, ActionView::Layouts)
class TestController < ActionController::Base
def send_mail
I18nTestMailer.mail_with_i18n_subject("test@localhost").deliver

@ -23,7 +23,7 @@
s.add_dependency 'rack', '~> 1.5.2'
s.add_dependency 'rack-test', '~> 0.6.2'
s.add_dependency 'actionview', version
s.add_development_dependency 'actionview', version
s.add_development_dependency 'activemodel', version
end

@ -13,6 +13,7 @@ def initialize(message = nil)
module Rendering
extend ActiveSupport::Concern
include ActionView::ViewPaths
# Normalize arguments, options and then delegates render_to_body and
# sticks the result in self.response_body.

@ -2,20 +2,6 @@
require "action_controller/metal/params_wrapper"
module ActionController
# The <tt>metal</tt> anonymous class was introduced to solve issue with including modules in <tt>ActionController::Base</tt>.
# Modules needs to be included in particluar order. First we need to have <tt>AbstractController::Rendering</tt> included,
# next we should include actuall implementation which would be for example <tt>ActionView::Rendering</tt> and after that
# <tt>ActionController::Rendering</tt>. This order must be preserved and as we want to have middle module included dynamicaly
# <tt>metal</tt> class was introduced. It has <tt>AbstractController::Rendering</tt> included and is parent class of
# <tt>ActionController::Base</tt> which includes <tt>ActionController::Rendering</tt>. If we include <tt>ActionView::Rendering</tt>
# beetween them to perserve the required order, we can simply do this by:
#
# ActionController::Base.superclass.send(:include, ActionView::Rendering)
#
metal = Class.new(Metal) do
include AbstractController::Rendering
end
# Action Controllers are the core of a web request in \Rails. They are made up of one or more actions that are executed
# on request and then either it renders a template or redirects to another action. An action is defined as a public method
# on the controller, which will automatically be made accessible to the web-server through \Rails Routes.
@ -174,7 +160,7 @@ module ActionController
# render action: "overthere" # won't be called if monkeys is nil
# end
#
class Base < metal
class Base < Metal
abstract!
# We document the request and response methods here because albeit they are
@ -214,6 +200,7 @@ def self.without_modules(*modules)
end
MODULES = [
AbstractController::Rendering,
AbstractController::Translation,
AbstractController::AssetPaths,
@ -221,6 +208,7 @@ def self.without_modules(*modules)
HideActions,
UrlFor,
Redirecting,
ActionView::Layouts,
Rendering,
Renderers::All,
ConditionalGet,

@ -38,7 +38,6 @@ class Railtie < Rails::Railtie # :nodoc:
initializer "action_view.setup_action_pack", before: :add_view_paths do |app|
ActiveSupport.on_load(:action_controller) do
ActionController::Base.superclass.send(:include, ActionView::Layouts)
ActionView::RoutingUrlFor.send(:include, ActionDispatch::Routing::UrlFor)
end
end

@ -267,8 +267,6 @@ def assert_header(name, value)
end
end
# Emulate AV railtie.
ActionController::Base.superclass.send(:include, ActionView::Layouts)
ActionView::RoutingUrlFor.send(:include, ActionDispatch::Routing::UrlFor)
module ActionController