parndt / decorators

Manages the process of loading decorators into your Rails application.

Decorators Plugin

This is a very simple plugin that adds support for decorators to your Rails application. Effectively all that this does is allow you to register paths in which to search for decorators which are then loaded at the appropriate point in your application's initialisation process.

Decorators must follow this naming convention:

app/decorators/<at least one subdirectory>/something_decorator.rb

This is an example of a decorator that will be loaded:

app/decorators/controllers/pages_controller_decorator.rb

These are examples of decorators that won't be loaded:

app/decorators/pages_controller_decorator.rb
app/decorators/controllers/pages_controller.rb

The important parts are being inside a sub directory of app/decorators and having _decorator.rb at the end of the file's name.

How to install

In your Gemfile, add the gem:

gem 'decorators', '~> 2.0.3'

Now, run bundle install and the gem should install.

How to use

There really is just one method to call; Decorators#register!. Simply pass one path or many paths to the method to register paths to search inside for decorators to be loaded from.

require 'decorators'
Decorators.register! Rails.root

Or for many paths:

require 'decorators'
Decorators.register! Rails.root, Rails.root.join('vendor', 'extensions', 'extension_with_decorators')

Avoiding Rails development mode reloading issues (example)

If you are loading this from within a Rails engine definition make sure you require the decorators library in the standard way, from outside of any method definitions:

+require 'decorators'
+
 module Namespaced
   class Engine < Rails::Engine

   initializer 'load decorators' do
-    require 'decorators'
     Decorators.register! Rails.root, Rails.root.join('vendor', 'extensions', 'namespaced')
   end
 end

If this is happening in the main application you can avoid this in config/application.rb:

 require File.expand_path('../boot', __FILE__)

 require 'rails/all'
+require 'decorators'

 if defined?(Bundler)
   # etc

License

Decorators is released under the MIT license and is copyright (c) 2013 Philip Arndt

decorators's Issues

1.0.4 Throws 'Eager Load' Error on Rails 3.2

I am working on a legacy Rails 3.2 application that requires decorators through forem. Decorators 1.0.4, in our setup, throws the following error when attempting to start the application on Heroku or with bundle exec thin start -R config.ru -e production:

/home/james/.rvm/rubies/ruby-2.1.4/lib/ruby/gems/2.1.0/gems/railties-3.2.17/lib/rails/railtie/configuration.rb:85:in `method_missing': undefined method `eager_load' for #<Rails::Application::Configuration:0x0000000555cb48> (NoMethodError)
        from /home/james/.rvm/rubies/ruby-2.1.4/lib/ruby/gems/2.1.0/gems/decorators-1.0.4/lib/decorators/railtie.rb:9:in `block in <class:Railtie>'

We're using Rails 3.2.17 and Railties 3.2.17. Not sure if this is intended behavior or not, but 1.0.3 works in our application, so this problem would go through pessimistic semver.

Thanks!

Draper etc

Hey there!

Figured since I also make files in app/decorators that I should throw in two cents here. I don't want to trample over others' decorators, either.

Is this something I should be supporting in some way?

`helper` in controller decorator is ignored/overwritten in production

I use the decorators gem among other things for monkey patching DeviseController. In the class_eval block I use helper to include my ApplicationHelper and other helpers. This works fine in development, but in production I get a NoMethodError in a view that tries to call a helper method in my ApplicationHelper.

I double checked that my decorator get's loaded. I also added a before_filter in the decorator and It's being called as well. Only the helpers aren't included.

Here's my code:

DeviseController.class_eval do
  layout 'admin'
  append_view_path 'app/views/admin'
  has_mobile_fu
  before_filter :init_js_framework_settings
  $stderr.puts('GETS LOADED!')

  protected

    def init_js_framework_settings
      @js_framework_settings = {
        namespace: self.class.name.split('::')[0..-2],
        controller: controller_name.camelize,
        action: action_name
      }
    end
end

Name seems deceiving

This probably because "Decorator" is a vague term, that can have a different meaning for each person.

The name to me seems like it would be for something that implements the decorator pattern; but, from your tweet, it appears this is for a different purpose. It seems like they are more like: Patchers, Patches, Mutators, or some other term that means it's modifying a class instead of wrapping instances of a class.

Duplicate loading when cache_classes=false and eager_load=true

For a variety of reasons I won't go into here, I have to run my app with eager_load = true in development (where cache_classes = false). (I realize this is an unusual Rails setup for development env).

I'm trying to use this gem to handle decoration loading, but in this situation, the decorator is loaded twice on application initialization, once when the code is eager loaded (because Rails eager loads app/**/*) and once when this gem runs its load! method.

I tried various fixes changing when/where Decorators.load! is run, but no luck. I was wondering if someone with a deeper understanding of the Rails autoloading and boot processes had any thoughts.