Sorry, Terracoding is no more as of August 2016. Thank you to all of our wonderful clients and partners over the last five years! It’s been a blast. – Dom, Rob & Sam

Natural Resource: Avoiding ActiveAdmin

Background

Natural Resource was born from frustrations experienced on legacy projects that used gems like ActiveAdmin to provide an admin interface for an app. For the very basics ActiveAdmin is great; it provides you a set of functionality out of the box that you don’t have to implement yourself.

Unfortunately, we are all aware that requirements change and functionality grows. ActiveAdmin forces you to extend it using its own concepts outside of standard Rails practices, sometimes going so far as to mix routing, controller and view details in the same file.

Rolling your own admin functionality?

After a frustrating few hours grappling with AA’s quirks, it’s easy to understand why someone would resort to rolling their own admin interface. Advanced admin features shouldn’t be any harder to implement than the rest of your app.

Secondly, it’s often hard to integrate large, opinionated admin gems because they try to blend authentication and/or authorisation logic with their own concepts. Whilst Natural Resource is also opinionated, it exists and performs in a very simple way and is easily overridden.

Enough talk - show me the code!

The following is a typical NR-based controller:

# Controller for generating and displaying Reports for orders received
class Admin::OrdersController < ApplicationController
  include AdminController
  include ReportDownloading

  resource :order

  def resource_scope
    Order.includes(:txns, line_items: [:product])
  end

  def report_class
    OrderReport
  end
end

If we take the above to have authenticated our admin-user (via your own AdminController concern) then our view could look like this:

%h1 Order Report

= search_form_for [current_context, query] do |f|
  = f.input :user_email_cont, label: 'Recipient Email'
  = f.input :amount_cents_gt, label: 'Amount greater than'
  = f.button :submit, "Apply filters"
  = link_to 'Download report', [:download, current_context, :orders,
    q: params[:q])

%table
  %tr
    %th Order Reference
    %th Payment Method
    %th Recipient Name
    %th Amount
    %th Created At
  - resources.each do |resource|
    %tr
      %td= resource.reference
      %td= resource.source_type.titleize
      %td= resource.user.name
      %td= resource.amount.format
      %td= resource.created_at

= will_paginate resources

The above controller offers several helper methods:

  • current_context is a method defined to specify the area of the site you are in. It is used for consistently defining routes.
  • query is the Ransack search object used for defining simple querying using the Ransack syntax.
  • resource_scope is the initial scope of the objects scoped via its respective policy, i.e. policy_scope(resource_scope)
  • resources is the lazy-loaded, paginated result of applying the Ransack query across the resource_scope method.

In Summary

The main motivation behind Natural Resource is to be pragmatic. There are further extensions that can be made to it to allow auto-generating initial views if a sensible standard set can be decided upon without introducing too much overhead/complexity.

It provides a rich set of foundational functionality and tries its best to take a sensible modular, easily overridden approach to standardised components.

There is an NR example repo that contains a more detailed example, but nothing beats reading the source. The majority of functionality is only ~100 lines long. I will add to the NR example repository as we use NR at Terracoding, converting the git history to a series of steps you can follow in the README.

Post Archive

2014

December

2013

December

January

2012

October

September