#21 new

Abstract out "Configuration" functionality from i18n into separate gem.

Reported by viatropos | June 17th, 2010 @ 12:11 AM


Not sure if there's an irc for i18n so I'm posting this here.

I am looking to build a sort of settings/configuration model that acts exactly like i18n, with a few extensions:

  • Use dot-separated keys to acts as a nested set (site.authentication.use_openid as a sample setting)
  • Allow settings to be unique to individual models (polymorphic belongs_to configurable)
  • Have a default set of configurations/settings that are overridden on a per-model-as-needed basis.

I just looked through the i18n code to see if it was doing something similar (that's where I got the idea for dot-separated keys to mimic a nested set). It looks pretty much the same...

So I'm wondering, what are your thoughts on extracting out that core "nested set configuration" functionality into an even more fundamental gem which i18n builds upon?

By "nested set configuration" I mean these are equivalent:

path.to.translation = "Hello World"
{:path => {:to => {:translation => "Hello World"}}}
Setting.find("path", :scope => "to.translation").value => "Hello World"

That way I can do things like this (I'm actually using this now for settings):

Settings do
  asset do
    thumb do
      width 100, :tip => "Thumb's width"
      height 100, :tip => "Thumb's height"
    medium do
      width 600, :tip => "Thumb's width"
      height 250, :tip => "Thumb's height"
    large do
      width 600, :tip => "Large's width"
      height 295, :tip => "Large's height"
  authentication do
    use_open_id true
    use_oauth true
    email "martini@example.com"
    password "martini"
  front_page do
    slideshow_tag "slideshow"
    slideshow_effect "fade"
  page do
    per_page 10
    feed_per_page 10
    formats "markdown", :options => ["textile", "markdown", "plain", "html", "haml"]
  people do
    show_avatars true
    default_avatar "/images/missing-person.png"
  site do
    title "Martini", :tooltip => "Main Site Title!"
    tagline "Developer Friendly, Client Ready Blog with Rails 3"
    keywords "Rails 3, Heroku, JQuery, HTML 5, Blog Engine, CSS3"
    copyright "© 2010 Viatropos. All rights reserved."
    menu :type => :integer,
      :value => lambda { Post.roots },
      :options => lambda { Post.roots.map {|p| [p.title, p.id]} }
    date_format "%m %d, %Y"
    time_format "%H"
    week_starts_on "Monday", :options => ["Monday", "Sunday", "Friday"]
    language "en-US", :options => ["en-US", "de"]
    touch_enabled true
    touch_as_subdomain false
    google_analytics ""
    logo "/images/logo-thumb.png"
    cache_duration 60
    permalink do
      default "/:title"
      date "/:date/:title"
      numeric "/:id"
      custom ""
    teasers do
      disable false
      left :type => :integer,
        :value => lambda { Post.first },
        :options => lambda { Post.tree {|p| [p.title, p.id]} }
      right :type => :integer,
        :value => lambda { Post.first },
        :options => lambda { Post.tree {|p| [p.title, p.id]} }
      center :type => :integer,
        :value => lambda { Post.first },
        :options => lambda { Post.tree {|p| [p.title, p.id]} }
    main_quote :type => :integer,
      :value => lambda { Post.first },
      :options => lambda { Post.tree {|p| [p.title, p.id]} }
  s3 do
    key "my_key"
    secret "my_secret"

Here's the benefit of doing this:

  • All applications that need Configuration (translations, preferences, app configuration, etc.) will only require one table

...something like this:

create_table :settings do |t|
  t.string  :scope #=> locale for translations
  t.string  :key
  t.string  :kind #=> or sti "type", "translations", "settings", etc.
  t.references :configurable, :polymorphic => true # what it's associated with (per-user settings for example), null if global
  t.text    :value
  t.text    :interpolations
  t.boolean :is_proc, :default => false
  • Efforts can be divided among two main tasks: translations, and optimizing storing key/values and everything that entails (handling procs for example).

Otherwise, if I want to create settings functionality, where Setting values are often procs (Post.all for instance), I have to copy most of the i18n code, or start from scratch.

Maybe something like this would be useful to others?

What are your thoughts?

Comments and changes to this ticket

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Internationalization API for Ruby.

This library is used in Ruby on Rails but also suited for use in other contexts.

People watching this ticket