通过Web表单使用户可以访问应用程序范围的设置

Question

I've been looking around all afternoon to try and find the dominant convention for setting up user-modifiable application-wide settings in Rails... no dice so far.

I'm working on a simple application which is intended to be used by one organization, so there's no need for a user model, there's only a single administrator. That administrator needs to have the ability to modify certain site-wide preferences, things like the logo, color scheme, tagline, etc.

What's the best practice for creating this kind of application-wide settings in Rails 3.1, and making them easily accessible to the end-user? Bonus points for any example apps you can link to.

Answer 1

The dominant convention to store editable app-wide settings seems to be the concept of a key-value store, backed either by ActiveRecord or other mechanisms. And, as far as I know, there are at least two nice strategies for storing your app-wide settings, depending on your requisites.

If you want a generic approach, yet extremely flexible for defining a couple of (not) scoped settings that can be in association with AR Models, you have Rails-Settings (or its cached version Rails-Settings-Cached ). I haven't tried using the plugin in Rails 3.1 but it works well on 3.0. It allows you to have things like:

Settings.main_color = '#3333CC'
Settings.logo_file_name = 'images/logo.png'
Setting['preferences.color'] = :blue

In case you want a robust approach, with Single-Table-Inheritance and allowing you to perform validations in certain settings as you would with actual AR Records, you have this nice article , written by Jeff Dean, which steps you through the process. This way you scope settings by grouping them into subclasses and you can have things like:

class ApplicationSettings::PageLayout < ApplicationSetting
  validates :title, :presence => true
  ...
  def title
    value
  end

  def title=(value)
    self.value = value
  end

And I guess that with some simple tuning you can even have has_many and belongs_to associations in some of your settings (like a variable-sized list of phone numbers or e-mails).

Personally I prefer the latter approach (when settings are a big issue) because it gives you more control over the settings you store and keeps your code clean and DRY, allowing you to follow the MVC pattern.

Answer 2

I generally set up a Properties model with some basic scaffolding in the admin section - then call the relevant Property 'field' where required, say Property.find(:field => "EARLIEST_DATE:YEAR") which would have a user settable value.

Properties might not be the best name for a database table (tend to think there's too much chance of a reserved name collision somewhere down the line) - but you get the idea. Advantage is you can set up scopes to access the values set by the user.