Forum: Ruby on Rails Changing class data in environmrnt.rb

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
62c90b6f399e6b95554b2da31ca8619a?d=identicon&s=25 Alex Wayne (Guest)
on 2006-04-13 02:45
(Received via mailing list)
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
D0cd6b10e01bacb976b3b815a9c660bc?d=identicon&s=25 Alex Wayne (Guest)
on 2006-04-16 09:13
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?
E28c35323f624b8b9ed8712e25105454?d=identicon&s=25 Ray Baxter (Guest)
on 2006-04-17 02:10
(Received via mailing list)
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.

--

Ray
D0cd6b10e01bacb976b3b815a9c660bc?d=identicon&s=25 Alex Wayne (Guest)
on 2006-04-17 19:33
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.
>
> --
>
> 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?
E28c35323f624b8b9ed8712e25105454?d=identicon&s=25 Ray Baxter (Guest)
on 2006-04-18 00:58
(Received via mailing list)
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
D0cd6b10e01bacb976b3b815a9c660bc?d=identicon&s=25 Alex Wayne (Guest)
on 2006-04-19 00:56
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.
>
> --
>
> 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!
This topic is locked and can not be replied to.