I’m in the process of deciding how a plugin should be designed to make
configuration as easy as possible. Right now I require the plugin from
init.rb, and set some configuration options (as class attribute
accessors) from environment.rb. Then I tried setting these from
environments/development.rb instead, and to my surprise this didn’t
work. It said the class in question hadn’t been loaded yet. So I guess
my question is in which order the global environment.rb, the
environtments/$RAILS_ENV.rb and plugins/*/init.rb gets run… Is there
any good way to add env-specific configuration to a plugin? Would kinda
come in handy, actually…
Yes, of course. I had a slight misconception about config/environment.rb
though. As far as I can find, this file is the one who actually runs the
Rails::Initializer. But if that’s the case, there’s no current way to
give different plugins different configurations based on environment
without doing a hack solution at the bottom of environment.rb.
For example, the case in point is my small authentication plugin for
CAS. Optimally, I would set this plugin to go to another server in
development (or even fake out the authentication completely while
developing.) … It doesn’t seem like the rails way (or the ruby way) to
add this at the end of environment.rb
if ENV[‘RAILS_ENV’] == 'development
CAS::Filter.fake = “test_person_uid”
else
CAS::Filter.login_url = “htt://cas.company.com/login”
end
Maybe I’m the only one with this problem. Is there any specific rational
behind doing load_plugins after load_environment?
“Yields falsehood when quined” yields falsehood when quined.
Ola-
You can look in rails/railties/lib/initializer.rb to see the order
in which things are loaded. Here is the relevant part:
# Sequentially step through all of the available initialization
routines,
# in order:
#
# * #set_load_path
# * #set_connection_adapters
# * #require_frameworks
# * #load_environment
# * #initialize_database
# * #initialize_logger
# * #initialize_framework_logging
# * #initialize_framework_views
# * #initialize_dependency_mechanism
# * #initialize_breakpoints
# * #initialize_whiny_nils
# * #initialize_framework_settings
# * #load_environment
# * #load_plugins
# * #initialize_routing
#
# (Note that #load_environment is invoked twice, once at the
start and
# once at the end, to support the legacy configuration style
where the
# environment could overwrite the defaults directly, instead of
via the
# Configuration instance.
def process
check_ruby_version
set_load_path
set_connection_adapters
require_frameworks
load_environment
initialize_database
initialize_logger
initialize_framework_logging
initialize_framework_views
initialize_dependency_mechanism
initialize_breakpoints
initialize_whiny_nils
initialize_temporary_directories
initialize_framework_settings
# Support for legacy configuration style where the environment
# could overwrite anything set from the defaults/global through
# the individual base class configurations.
load_environment
add_support_load_paths
load_plugins
# Routing must be initialized after plugins to allow the
former to extend the routes
initialize_routing
# the framework is now fully initialized
after_initialize
end
Cheers-
-Ezra
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.