Greetings, I have a class that should allow you define some default values. It seems to make the most sense to do this environment.rb since its the default app configuration. It currently looks like this: Settings::DEFAULT_VALUES.merge!({ :setting_one => ''foo'', :settings_two => ''bar'' }) The problem is in development mode, the values are only there for the first request after launching webrick. After the first request the entries have dissapeared form the class. In development mode the changes persist and are around for any number of requests. Specifically it seems to be the cache_class setting. It seems the class is destroyed and recreated when not cached for each request, although environment.rb is only run the first time. I modeled this solution off of various rails settings, like: ActiveSupport::CoreExtensions::Time::Conversions::DATE_FORMATS.merge!({:date => ''%b %d, %Y''}) But it would seem that the core rails stuff is cached no matter what environment settings. So what is the best way to include configuration of a custom class that works in development mode? Running a before_filter in application.rb seems like a messy solution. Any ideas? -Alex
No ideas at all? Alex Wayne wrote:> I have a class that should allow you define some default values. My > stuff in environment.rb currently looks like this: > > Settings::DEFAULT_VALUES.merge!({:setting_one => ''foo''}) > > The problem is in development mode, the values are only there for the > first request. After the first request the > entries have dissapeared form the class. In development mode the > changes persist and are around for any number of requests. Specifically > it seems to be the cache_class setting. It seems the class is destroyed > and recreated when not cached for each request, although environment.rb > is only run the first time. > > Anyway without a before_filter to do this?-- Posted via http://www.ruby-forum.com/.
Alex Wayne wrote:> No ideas at all? > > Alex Wayne wrote: >> I have a class that should allow you define some default values. My >> stuff in environment.rb currently looks like this: >> >> Settings::DEFAULT_VALUES.merge!({:setting_one => ''foo''}) >> >> The problem is in development mode, the values are only there for the >> first request. After the first request the >> entries have dissapeared form the class. In development mode the >> changes persist and are around for any number of requests. Specifically >> it seems to be the cache_class setting. It seems the class is destroyed >> and recreated when not cached for each request, although environment.rb >> is only run the first time. >> >> Anyway without a before_filter to do this?Could you ask your question again? I have something like this working in both production and development, but your question seems to have a typo involving the word development. -- Ray
Ray Baxter wrote:> Alex Wayne wrote: >>> entries have dissapeared form the class. In development mode the >>> changes persist and are around for any number of requests. Specifically >>> it seems to be the cache_class setting. It seems the class is destroyed >>> and recreated when not cached for each request, although environment.rb >>> is only run the first time. >>> >>> Anyway without a before_filter to do this? > > Could you ask your question again? > > I have something like this working in both production and development, > but your question seems to have a typo involving the word development. > > -- > > RayIndeed there was a confusing typo. I have a class that should allow you define some default values. It seems to make the most sense to do this environment.rb since its the default app configuration. It currently looks like this: Settings::DEFAULT_VALUES.merge!({ :setting_one => ''foo'', :settings_two => ''bar'' }) The problem is in development mode, the values are only there for the first request after launching webrick. After the first request the entries have dissapeared form the class. In production mode the changes persist and are around for any number of requests. Specifically it seems to be the cache_class setting. It seems the class is destroyed and recreated when not cached for each request, although environment.rb is only run the first time. I modeled this solution off of various rails settings, like: ActiveSupport::CoreExtensions::Time::Conversions::DATE_FORMATS.merge!({:date => ''%b %d, %Y''}) But it would seem that the core rails stuff is cached no matter what environment settings. So what is the best way to include configuration of a custom class that works in development mode? Running a before_filter in application.rb seems like a messy solution. So Ray, how exactly did you make this work in development mode? -- Posted via http://www.ruby-forum.com/.
Alex Wayne wrote:> So Ray, how exactly did you make this work in development mode?I think it''s the merge! that is causing this problem. Where is Settings defined? Wherever that is is being reinitialized on every execution, but as you say, your environment.rb is only read the first time. I just defined the whole config in environment.rb. Here''s a snippet from my environment.rb module EventsConfig PARAMS = { # Custom parameters for display of events # Default order for sorting events :default_sorting_key => "date", # Default number of events per page :default_per_page => 30, # When do cookies expire :days_until_login_cookies_expire => 14.days } end Then I access what I need by EventsConfig::PARAMS[:default_per_page] Hope that helps. -- Ray
Ray Baxter wrote:> Alex Wayne wrote: > >> So Ray, how exactly did you make this work in development mode? > > I think it''s the merge! that is causing this problem. Where is Settings > defined? Wherever that is is being reinitialized on every execution, but > as you say, your environment.rb is only read the first time. > > I just defined the whole config in environment.rb. > > Here''s a snippet from my environment.rb > > module EventsConfig > PARAMS = { > # Custom parameters for display of events > > # Default order for sorting events > :default_sorting_key => "date", > > # Default number of events per page > :default_per_page => 30, > > # When do cookies expire > :days_until_login_cookies_expire => 14.days > } > end > > Then I access what I need by EventsConfig::PARAMS[:default_per_page] > > Hope that helps. > > -- > > RayThank you. Using a module to house the settings is a great idea because it persists. And to make it as flexible as possible, I added this to my Settings class: @@defaults = (defined?(SettingsDefaults) ? SettingsDefaults::DEFAULTS : {}).with_indifferent_access making the SettingsDefaults module entirely optional. Thanks for the tip! -- Posted via http://www.ruby-forum.com/.