Zastanawiałem się, jak dodać niestandardowe zmienne konfiguracyjne do aplikacji railsowej i jak uzyskać do nich dostęp w kontrolerze, np. Chcę zdefiniować katalog upload_directory w plikach konfiguracyjnych, powiedz develop.rb i mieć do niego dostęp w jednym z moich kontrolery.

Po drugie, planowałem mieć wsparcie S3 dla przesyłania w mojej aplikacji, jeśli chciałbym dodać plik yaml z dostępem s3, tajnym kluczem, jak zainicjować go w mojej aplikacji Rails i jak uzyskać dostęp do wartości, które zdefiniowałem w tym pliku konfiguracyjnym.

Aktualizacja 1

Bardzo zalecane: Idę teraz z klejnotem Rails Config, aby zapewnić precyzyjną kontrolę, jaką zapewnia.

Aktualizacja 2

Jeśli chcesz szybkiego rozwiązania, sprawdź odpowiedź Jacka Pratta poniżej.

Chociaż moja pierwotna odpowiedź poniżej nadal działa, ta odpowiedź jest obecnie nieaktualna. Polecam przejrzenie aktualizacji 1 i 2.

Oryginalna odpowiedź:

Aby uzyskać szybkie rozwiązanie, bardzo pomocne może być wyświetlenie ekranu „Plik konfiguracyjny YAML” przesłanego przez Ryana Batesa.

W podsumowaniu:

# config/initializers/load_config.rb
APP_CONFIG = YAML.load_file("#{Rails.root}/config/config.yml")[Rails.env]

# application.rb
if APP_CONFIG['perform_authentication']
  # Do stuff
end

W Rails 3 niestandardowe dane konfiguracyjne specyficzne dla aplikacji można umieścić w obiekcie konfiguracji aplikacji. Konfigurację można przypisać w plikach inicjujących lub plikach środowiska - powiedzmy dla danej aplikacji MyApp:

MyApp::Application.config.custom_config_variable = :my_config_setting

lub

Rails.configuration.custom_config_variable = :my_config_setting

Aby odczytać ustawienie, po prostu wywołaj zmienną konfiguracyjną bez jej ustawiania:

Rails.configuration.custom_config_variable
=> :my_config_setting

AKTUALIZACJA Szyny 4

W Rails 4 jest nowy sposób na to => http://guides.rubyonrails.org/configuring.html#custom-configuration

W Railsach 3.0.5 działało dla mnie następujące podejście:

W config/environments/development.rb, napisz

config.custom_config_key = :config_value

Do wartości custom_config_keymożna następnie odwoływać się z innych plików za pomocą

Rails.application.config.custom_config_key

Działa to w szynach 3.1:

w config / environment.rb (lub w config / environment / .., aby wybrać określone środowisko):

YourApp::Application.config.yourKey = 'foo'

Będzie to dostępne w kontrolerze lub widokach takich jak ten:

YourApp::Application.config.yourKey

(Twoja aplikacja powinna zostać zastąpiona nazwą aplikacji).

Uwaga : To jest kod Ruby, więc jeśli masz dużo kluczy konfiguracji, możesz to zrobić:

w config / environment.rb:

YourApp::Application.configure do
  config.something = foo
  config.....
  config....
  .
  config....
end

W szynach 4

Zakładając, że umieścisz zmienne niestandardowe w pliku yaml:

# config/acme.yml
development:
  :api_user: 'joe'
  :api_pass: 's4cret'
  :timeout: 20

Utwórz inicjator, aby je załadować:

# config/initializers/acme.rb
acme_config = Rails.application.config_for :acme

Rails.application.configure do
  config.acme = ActiveSupport::OrderedOptions.new
  config.acme.api_user = acme_config[:api_user]
  config.acme.api_pass = acme_config[:api_pass]
  config.acme.timeout  = acme_config[:timeout]
end

Teraz w dowolnym miejscu aplikacji możesz uzyskać dostęp do tych wartości:

Rails.configuration.acme.api_user

Jest to wygodne, Rails.application.config_for :acmeaby załadować acme.ymli korzystać z odpowiedniego środowiska.

Ponieważ Rails 4.2, bez dodatkowych klejnotów, możesz załadować config / hi.yml po prostu używającRails.application.config_for :hi .

Na przykład:

1. touch config/passwords.yml

       #config/passwords.yml
       development:
         username: 'a'
         password: 'b'
       production:
         username: 'aa'
         password: 'bb'

2. touch config/initializers/constants.rb

   #config/initializers/constants.rb
   AUTHENTICATION = Rails.application.config_for :passwords

3. a teraz możesz używać AUTHENTICATIONstałej wszędzie w swojej aplikacji:

   #rails c production
   :001> AUTHENTICATION['username'] => 'aa'

4. następnie dodać passwords.yml do .gitignore : echo /config/passwords.yml >> .gitignoreutwórz plik Przykład Dla Państwa komfortu cp /config/passwords.yml /config/passwords.example.ymli potem po prostu zmienić swój przykładowy plik w konsoli produkcyjnej z rzeczywistych wartości produkcji.

Chciałem tylko zaktualizować to, aby uzyskać najnowsze fajne rzeczy w Rails 4.2, teraz możesz to zrobić w dowolnym ze swoich config/**/*.rbplików:

config.x.whatever.you.want = 42

... a będzie to dostępne w Twojej aplikacji jako:

Rails.configuration.x.whatever.you.want

Zobacz więcej tutaj: http://guides.rubyonrails.org/configuring.html#custom-configuration

Sprawdź ten zgrabny klejnot, robiąc dokładnie to: https://github.com/mislav/choices

W ten sposób Twoje wrażliwe dane nie zostaną ujawnione w projektach open source

Stworzyłem prostą wtyczkę do ustawień YAML: Yettings

Działa w podobny sposób jak kod w odpowiedzi khelll, ale wystarczy dodać ten plik konfiguracyjny YAML:

app/config/yetting.yml

Wtyczka dynamicznie tworzy klasę, która pozwala na dostęp do ustawień YML jako metod klas w Twojej aplikacji, takich jak:

Yetting.your_setting

Ponadto, jeśli chcesz użyć wielu plików ustawień o unikalnych nazwach, możesz umieścić je w podkatalogu w aplikacji / config w następujący sposób:

app/config/yettings/first.yml
app/config/yettings/second.yml

Następnie możesz uzyskać dostęp do takich wartości:

FirstYetting.your_setting
SecondYetting.your_setting

Zapewnia również domyślne ustawienia, które można zastąpić w zależności od środowiska. Możesz także użyć erb w pliku yml.

Naprawdę podoba mi się klejnot settingslogic . Bardzo łatwy w konfiguracji i obsłudze.

https://github.com/binarylogic/settingslogic

Jeśli używasz Heroku lub w inny sposób musisz zachować ustawienia aplikacji jako zmienne środowiskowe, klejnot figaro jest bardzo pomocny.

Lubię używać ustawień szyn do globalnych wartości konfiguracyjnych, które muszą być zmieniane przez interfejs WWW.

Coś, co zaczynamy robić w pracy to uporządkowany skrót ActiveSupport

Co pozwala ci czysto zdefiniować konfigurację w plikach środowiska np

config.service = ActiveSupport::OrderedOptions.new
config.service.api_key = ENV['SERVICE_API_KEY']
config.service.shared_secret = ENV['SERVICE_SHARED_SECRET']

Sugeruję dobre podejście, jak w ogóle poradzić sobie z konfiguracją w twojej aplikacji. Istnieją trzy podstawowe zasady:

• zmień konfigurację, a nie kod;
• używaj konfiguracji ponad warunkami;
• napisz kod, który coś znaczy.

Aby uzyskać bardziej szczegółowy przegląd, skorzystaj z tego łącza: Konfiguracja szyn we właściwy sposób