Question

We will soon be rewriting a 5 year old rails app, with a very unsound code foundation, from scratch in a brand new Rails 3 app with all the new hotness. The current app has a substantial custom admin UI backend which depends on now admin frameworks at all. Just some base controller classes and some somewhat useful CSS conventions. But maintaining that UI is a lot of work, especially if we want it to look half way nice.

So I’m in the market for an Admin UI framework that will make the simple stuff trivial, but without getting the way of more complex customization in both form and function.

The top contender, ActiveAdmin, seems to be very popular, and after playing with it a bit I have some concerns. It seems to declare a whole unique DSL that exists in a single ruby file. This is kind of neat, but it’s also a completely different than how most other Rails apps are architected. It abstracts away the view, the helper the controller, and gives you a pure ruby DSL. It seems to me that this would get in the way of doing tricky things, more advanced custom things in our admin views. DSL’s are great, until you want to do something they don’t explicitly support.

Example “Resource” from my experimentation, with no controller and no view.

ActiveAdmin.register Region do
  menu parent: "Wines"

  show title: :name

  index do
    column(:zone) { |o| link_to o.zone, admin_region_path(o) }
    column(:name) { |o| link_to o.name, admin_region_path(o) }
    default_actions
  end  
end

So, the questions:

1. Is not being based on the standard Rails MVC architecture in separate files, and the typical controller inheritance based implementation of an admin area, actually something I should be concerned about? Will it hamper extensibility in the long term?
2. Is the DSL in ActiveAdmin better and more flexible than I’m giving it credit for?
3. Should I be looking at some other framework that lends itself better to my goals of high customization?
4. Should I stop being lazy and roll my own?
5. Does the choice of Mongoid instead of MySQL as a database affect any of the above questions?

Answer 1

+1 for active admin, I use it in many projects, including a cms I’m building. It indeed is more flexible than many people who are newer with it give it credit for, at the end of the day you can always do:

controller do
  def custom_action
    Puts "hi"
  end
end

(Think that’s the right syntax writing from phone so all this is off top of head)

Also, I swear by inherited resources, which active admin controllers extend, as they really force you (in a good way) into writing restful, reuse able code. Bottom line is I believe active admin is leaps and bounds ahead of the others I’ve tried (railsadmin and at least one other)

Update:
Sure, here is the inherited_resources documentation

https://github.com/josevalim/inherited_resources

And here is an example of modifying the controller directly, from my little CMS project.

ActiveAdmin.register Channel do

  index do
    column :title
    column :slug
    column "Fields" do |channel|
      "#{link_to('View Fields', admin_channel_entry_fields_path(channel))}    #{link_to 'Add Field', new_admin_channel_entry_field_path(channel)}".html_safe      
    end  
    column "Actions" do |channel|
      "#{link_to('View Entries', admin_channel_entries_path(channel))}    #{link_to 'Create Entry', new_admin_channel_entry_path(channel)}".html_safe
    end
    default_actions
  end

  form :html => { :enctype => "multipart/form-data" } do |f|
    f.inputs "Channel" do
      f.input :title
      f.input :display_name
      f.input :image
    end
    f.buttons
  end

  controller do

    def begin_of_association_chain
      current_site
    end

    def tags

      query = params[:q]
       if query[-1,1] == " "
         query = query.gsub(" ", "")
         ActsAsTaggableOn::Tag.find_or_create_by_name(query)
       end

       @tags = ActsAsTaggableOn::Tag.all
       @tags = @tags.select { |v| v.name =~ /#{query}/i }
       respond_to do |format|
         format.json { render :json => @tags.collect{|t| {:id => t.name, :name => t.name }}}
       end

    end

  end

end

Basically, I am using the inherited resources, begin_of_association_chain method (one of my favorite things about IR), to scope all the data within channels, or any of the admin resources that inherit from my channels resource, to the current site, without having a url like /admin/sites/1/channels — Because I am already setting current_site based on the url the visitor enters with. — Anyways, basically once you are inside:

controller do
  puts self.inspect
end

Returns the actual controller itself, e.g. Admin::ChannelsController (which < InheritedResources::Base, maybe not directly but all the IH controller methods should be available at this point).