Skip to content

Add option for dynamic modules #67

merged 3 commits into from Mar 6, 2013

3 participants

dipth commented Feb 22, 2013

Especially handy in a multi-tenancy setup where each tenant might not want the same modules and keys.

@dipth dipth Add option for dynamic modules
Especially handy in a multi-tenancy setup where each tenant might not want the same modules and keys.
dipth commented Feb 28, 2013

@jkrall do you have time to take a look at this one?


I'm still not decided on whether we should include this or not, but I think if we include this it could auto-detect whether we're passing in custom module configuration by checking if the modules are an array or a hash:

# original
analytical :modules => [:google]
# augmented
analytical :modules => { google: {...}, kissmetrics: {...} }
# or in your case:
analytical :modules => lambda{ |controller| controller.analytical_modules }

The point is I'd rather not add a separate configuration key for this if possible.

dipth commented Mar 1, 2013

@sfsekaran you mean something like this?

@dipth dipth Update README to reflect changes
and selflessly add myself to the list of contributors.

Yes, much like that :+1:

I'd like to get another maintainer's opinion before merging. @nirvdrum or @freerobby, any problems with this non-intrusive feature?

nirvdrum commented Mar 4, 2013

Overall, I really like this. I don't want to bikeshed, but it might be nice if the Proc variant had a way to fallback to whatever the config file has. Maybe if its yielded value is nil, you treat it as a no-op. E.g., it could be used to override config for just certain controllers or maybe just certain environments. But that could be done later as well.

dipth commented Mar 4, 2013

@nirvdrum I like your idea but it might be a bit tricky to implement without changing the API or adding new config-keys.

The problem is that if we pass a modules-option to the call to analytical, the modules loaded from the yml-file never actually gets stored anywhere.

One way to do it would be like this:

  def analytical(options={})
    self.analytical_options = options

    config_options = { :modules => [], :file_modules => [] }"#{::Rails.root}/config/analytical.yml") do |f|
      file_options = YAML::load(
      env = (::Rails.env || :production).to_sym
      file_options = file_options[env] if file_options.has_key?(env)
      file_options.each do |k, v|
        if v.respond_to?(:symbolize_keys)
          # module configuration
          config_options[k.to_sym] = v.symbolize_keys
          config_options[:modules] << k.to_sym unless options && options[:modules]
          config_options[:file_modules] << k.to_sym
          # regular option
          config_options[k.to_sym] = v
      end if file_options
    end if File.exists?("#{::Rails.root}/config/analytical.yml")

    self.analytical_options = self.analytical_options.reverse_merge config_options

Which makes sure that we can later see what modules were originally loaded from the yml-file, but then we are back at the original problem with introducing another key in the configuration hash


@nirvdrum, good point, and thanks @dipth for elaborating. Based on this, I'm going to merge this request and we can investigate good fallback support afterward. :hammer:

@sfsekaran sfsekaran merged commit a0dc4f4 into jkrall:master Mar 6, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.