When do you use initializer vs environments/*.rb

Hi,

I am setting up my smtp settings. In the past I would put them in
config/environments/development.rb for my development environment and
config/environments/production.rb for my production envrionment.

However Rails 2.0 seems to be encouraging people to create their own
initializers, such as mail.rb, under config/initializers. Is it
better to do it this way? If I do it that way how do I differentiate
envrionments?


Frank K.

I’m no expert, but I think initializers are only to keep your
environment.rb file clean, and you can’t differentiate between
environments.

That’s what I’m inferring from
http://ryandaigle.com/articles/2007/2/23/what-s-new-in-edge-rails-stop-littering-your-evnrionment-rb-with-custom-initializations

On 31 Mar 2008, at 08:29, Mike Nicholaides wrote:

I’m no expert, but I think initializers are only to keep your
environment.rb file clean, and you can’t differentiate between
environments.

Well… you can. What you can’t do, is use different files for a
different environment. The files in initializers are “appended” to the
general environment.rb if you will. That means you can still use
conditional rails environment detection (if RAILS_ENV==“production”).

Another big advantage of the initializers to us is capistrano
deployment. We have a certain application that needs to be rolled out
to several private customer servers, each with their own settings
(e.g. SMTP server for one customer, sendmail for another, …). In the
past, we’d have to keep a different environment.rb file for each
customer, even if 90% of all data in there was exactly the same. With
the initializers, we can just write away a custom configuration if
there’s a need.

That’s what I’m inferring from
http://ryandaigle.com/articles/2007/2/23/what-s-new-in-edge-rails-stop-littering-your-evnrionment-rb-with-custom-initializations

Best regards

Peter De Berdt

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs