Changing class data in environmrnt.rb

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 W. 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?

Alex W. 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.

Ray

Alex W. 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 B. wrote:

Alex W. 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.

Ray

Indeed 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?

Ray B. wrote:

Alex W. 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

Thank 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!