Dobro

Installation

First things first, get the gem in your Gemfile:

gem 'dobro', '~> 0.1.0'

Then, decide where you want it amongst your routes:

# in your config/routes.rb
dobro_for :articles, :pages, :users

If you want a central dobro page (which defaults to the index page for the first resource that you’re using with Dobro), just point a path to dobro/application#index:

# in your config/routes.rb
match '/dobro' => 'dobro/application#index'

And finally, make sure you add an identifier method to the models you’ve marked as Dobro resources. This may be the name, email address, or title. Best to make it something unique.

def identifier
  name
end

Bundle and restart your server, and you’re good to go. If you’ve provided a dobro index page (as covered above), then you can head straight to http://localhost:3000/dobro.

Before you get too carried away though, you’ll almost certainly want to edit the views so the forms have only the fields you’d like. Keep reading for details on that.

Usage

Customising the _form.html.erb and _show.html.erb partials for each of your resources is highly recommended. You can also add a _dashboard.html.erb, which will show up on resource indices.

It’s not recommended, but you’re also welcome to customise the views. Just put your versions in app/views/dobro, broken down by resources. For example, a custom edit view for users would end up in app/views/dobro/users/edit.html.erb.

The standard set of views for Dobro includes:

  • index
  • show
  • new
  • edit
  • delete

And perhaps you want to add custom controllers into the mix? That’s easy too. For the relevant resources, just give them their own dobro_for call, and specify the custom controller:

dobro_for :pages, :controller => 'pages'

You can also add additional routes just like a standard resources call:

dobro_for :pages, :controller => 'pages' do
  member { put :approve }
end

Compatibility

Developed for Rails 3.1 and Ruby 1.9. It will work on other Rubies, but not older versions of Rails.

Developing

Contributions are very much welcome – but keep in mind the following:

  • Keep patches in a separate branch
  • Don’t mess with the version or history file. We’ll take care of that when the patch is merged in.
  • Write tests – look at the existing tests (particularly in spec/acceptance) for examples and guidance.

Credits

Copyright © 2011 Hyper Tiny. The bulk of the work has been done by Brian Flanagan, Paul Campbell and Pat Allan, and the code is released under the open MIT Licence.