At Twin Engine Labs we recently discovered the joy that is Jose Valim’s Inherited Resources. For the unfamiliar, it takes all those generic REST actions and views and abstracts them all out for you, so your controllers simply inherit from InheritedResources::Base and you get the basics for free. For us, that means that a large portion of our web app admins are already written for us; we just tweak as needed.
My one real gripe, thus far, has been that the generated views Inherited Resources gives you are just too generic. It defaults to displaying all the attributes for an ActiveRecord resource on the form, show, and index pages, and many of those fields are simply of no use. We use Paperclip for all of our file attachments, which adds 4 database fields to represent each attachment (for an attachment named image you end up with image_file_name, image_content_type, image_file_size, and image_updated_at). None of these fields needs to actually be displayed to the user, nor will the users ever edit them directly.
Then there’s default Rails fields like created_at and updated_at, plus all your foreign keys for belongs_to associations. While you may want to display the date fields, you generally don’t want those editable by a user, and I’d rather show the belongs_to association directly than the foreign key. On top of this, we use Formtastic for generating forms, so if I could build a more reliable list of attributes and associations that were editable by a user, I could just hand them off to semantic_form_for and let it works its magic.
Enter the Decorator pattern. By creating a generic decorator to wrap my ActiveRecord resource_classes, I could use Rails’ magic to get a more refined list, then just use that decorator in all the Inherited Resources views. My base Decorator looks like this:
module InheritedResources
class Decorator
def initialize(klass)
@klass = klass
end
def form_attributes
edit_attrs = editable_attributes.reject {|a| a.to_s =~ /created_at|updated_at/}
edit_attrs + belongs_to_associations.map(&:name) + paperclip_attachments
end
def show_attributes
editable_attributes
end
def index_attributes
editable_attributes
end
def editable_attributes
assocs = belongs_to_associations
attach = paperclip_attachments
regex = "^id$"
regex << ('|' + assocs.map(&:foreign_key).join('|')) unless assocs.blank?
regex << ('|' + attach_attachments.join('|')) unless attach.blank?
@klass.attribute_names.reject { |an| an =~ /#{regex}/ }.map(&:to_sym)
end
def belongs_to_associations
@klass.reflect_on_all_associations.select { |a| a.macro == :belongs_to }
end
def paperclip_attachments
@klass.attachment_definitions ? @klass.attachment_definitions.keys : []
end
def method_missing(name, *args)
@klass.send(name, *args)
end
end
end
Next I added a helper method to our ResourceController which all of our admin controllers inherit from:
helper_method :decorated_resource_class
def decorated_resource_class
"InheritedResources::#{resource_class}Decorator".constantize.new(resource_class)
rescue InheritedResources::Decorator.new(resource_class)
end
As you’ll notice, I first try to instantiate a resource_class-specific version of the decorator, because I wanted to be able to subclass and override methods as needed. Finally I just went through all the generated resource views and replaced resource_class with decorated_resource_class and used the relevant methods to provide the attributes I wanted (e.g: #form_attributes in _form.html.erb, #show_attributes in show.html.erb, etc…).
What this means is that, at least for the basic, generic pages, I no longer have to override the provided views to get the desired output. And if I find these sane defaults don’t work, but I don’t need anything really custom, I can just subclass the Decorator for the specific resource_class and override the methods as needed. An example I immediately ran into was our User pages:
module InheritedResources
class UserDecorator < Decorator
def index_attributes
[:first_name, :last_name, :email, :current_city]
end
def show_attributes
index_attributes + [... some more attributes ...]
end
def form_attributes
show_attributes - [... some different attributes ...]
end
end
end
Of course, this won’t cover 100% of the cases, but I found it covers 80% – 90% of the views we use in a standard admin. The rest are so customized that over-riding the views is the only option anyway. I considered gemifying this, or making it a pull request for Inherited Resources, but since it’s built around our development environment, I think for now I’ll leave it as is.
