Unless I'm mistaken, anything you create in environment.rb persists
until server restart because environment.rb is a load-once file.
There are several plugins for storing settings (n/v pairs), but if
you want to persist page state like WinForms on Asp.Net, this isn't
the method for you.
If you're casting about for a way to store options and don't want to
go the plugin route, stick this in RAILS_ROOT/lib and they you can
write code like:
Unless I'm mistaken, anything you create in environment.rb persists
until server restart because environment.rb is a load-once file.
There are several plugins for storing settings (n/v pairs), but if
you want to persist page state like WinForms on Asp.Net, this isn't
the method for you.
If you're casting about for a way to store options and don't want to
go the plugin route, stick this in RAILS_ROOT/lib and they you can
write code like:
# options.rb
#
# Provide a container for global option storage
# Both getter/setter and access methods are
# provided.
class Options
@@option_hash = {}
def self.set(option_name, value)
option_name = option_name.to_s
@@option_hash[option_name] = value
end
def self.get(option_name)
option_name = option_name.to_s
@@option_hash[option_name]
end
def self.=(option_name, value)
option_name = option_name.to_s
self.set(option_name, value)
end
def self.(option_name)
option_name = option_name.to_s
self.get(option_name)
end
def self.has_key?(key)
key = key.to_s
@@option_hash.has_key?(key)
end
def self.key?(key)
self.has_key?(key)
end
end
Keep in mind this will not work when you run more then one rails backend. As each mongrel or fcgi will have a separate copy of this class and you are not always garaunteed that your users will always hit the same backend. So you will have to use the session, memcached or a DRb server for global state because it needs to be an external process that all rails backends can talk to to keep the data consistent. Or you also use the database to store state too.
Good point. This was lifted from some of my code that uses it on app
startup to store app-wide setup info. Of course when each backend is
fired up it is stuffed with the same information so 'sall good.
Application state can better be preserved using memcached or dRb or
even AR-sessions. Just don't save too much state
