Playing with Merb

Posted by glenn on Thursday, January 17, 2008

Posted in haml, merb

So there has been quite a lot of talk of late about merb, the new up and comer vying for the rails crown. It was initially developed by Ezra of EngineYard fame, and itâs generally considered that âThey know their stuffâ(tm). So what is merb? Is it a viable alternative to rails? How easy/hard is the migration from one to the other?

I figured it was long overdue that I take a look.

What is Merb? How is it different to Ruby on Rails?

Merb is a Rails-inspired MVC framework for web application development. Itâs major point of difference with Rails is that itâs not so prescriptive on what external libraries you have to use. Donât like prototype/scriptaculous? Swap it out for JQuery or Moo. Donât like ActiveRecord? Try DataMapper or Sequel instead. One of the implications of this is that it means that no longer do you have to fire up a cluster of mongrels to compensate for the fact that aspects of rails arenât thread safe.

Getting started with Merb

Installing it is simple as Ezra and the crew have made it available as a gem.

sudo gem install merb

Then to create a new application skeleton and get started itâs just:

merb my_app

So far it should seem fairly familiar! But how do we start playing with our database?

Connecting to a database

Well because merb doesnât impose any decisions on what ORM to use, you need to install your own. You can stick with ActiveRecord if you like, but letâs try something new.

sudo gem install datamapper merb_datamapper do_mysql

Weâve just installed the DataMapper ORM, the merb interface, and the mysql drivers. Next thing to do to test connecting to a database is setup the connection, and create a model. Update the config/dependencies.rb file and uncomment the following line:

### Uncomment for DataMapper ORM
use_orm :datamapper

Next we need to create a config/database.yml file which should be nothing shocking to look at:

---
# This is a sample database file for the DataMapper ORM
:development: &defaults
  :adapter: mysql
  :database: myapp_development
  :username: root
  :password:
  :host: localhost

:test:
  <<: *defaults
  :database: myapp_test

:production:
  <<: *defaults
  :database: myapp_production

and now the joy of creating a model:

script/generate model person --skip-migration

Skip migrations? Are you mad? Do I have to go back creating tables myself? Bear with me here, Iâll touch on migrations shortly. Next Iâll define some properties on my model in apps/models/person.rb:

class Person < DataMapper::Base
  property :name, :string
  property :dob, :date
end

Migrations with DataMapper

So weâve planned out our model, added in the properties we need. Now if only we could add/retrieve records to/from a table? Creating the required schema in the database is one line:

rake dm:db:automigrate

Thatâs right, DataMapper has automated migrations. It will infer from your model definitions what fields need to exist and create them as appropriate. Itâll also take care of primary and foreign keys too! You need to be careful though, because remove a column from the model definition and the next time you automigrate youâll lose that column in the DB too.

So what about the views? What templating systems do I have?

Okay, so creating models isnât too difficult or different from rails. Thankfully the same is true of views too. You can use erubius if you like, but to keep things as close to my version of ânormalâ as possible Iâm sticking with HAML. So itâs really business as usual on this front. Create your views as you normally would, and it should âjust workâ

Watch this space for a deeper end-to-end tutorial or screen cast where Iâll have a full basic app. Feel free to shoot through any ideas you have.

Glenn Gillen is a ruby, merb, and ruby on rails developer with clients in London, New York, Los Angeles, and Australia. Contact Ruby Pond if you wish to discuss hiring Glenn or one of our other developers for your own project.