Camping, a Microframework

Camping is a web framework which consistently stays at less than 4kb of code. You can probably view the complete source code on a single page. But, you know, it’s so small that, if you think about it, what can it really do?

The idea here is to store a complete fledgling web application in a single file like many small CGIs. But to organize it as a Model-View-Controller application like Rails does. You can then easily move it to Rails once you’ve got it going.

A Camping Skeleton

A skeletal Camping blog could look like this:

require 'camping'

Camping.goes :Blog

module Blog::Models
  class Post < Base; belongs_to :user; end
  class Comment < Base; belongs_to :user; end
  class User < Base; end
end

module Blog::Controllers
  class Index < R '/'
    def get
      @posts = Post.find :all
      render :index
    end
  end
end

module Blog::Views
  def layout
    html do
      body do
        self << yield
      end
    end
  end

  def index
    for post in @posts
      h1 post.title
    end
  end
end

if __FILE__ == $0
  Blog::Models::Base.establish_connection :adapter => 'sqlite3', 
      :database => 'blog3.db'
  Blog::Models::Base.logger = Logger.new('camping.log')
  puts Blog.run
end

Some things you might have noticed:

  • Camping::Models uses ActiveRecord to do its work. We love ActiveRecord!

  • Camping::Controllers can be assigned URLs in the class definition. Neat?

  • Camping::Views describes HTML using pure Ruby. Markup as Ruby, which we call Markaby.

  • You use Camping::goes to make a copy of the Camping framework under your own module name (in this case: Blog.)

NOTE: Camping auto-prefixes table names. If your class is named Blog::Models::Post, your table will be called blog_posts. Since many Camping apps can be attached to a database at once, this helps prevent name clash.

(If you want to see the full blog example, check out examples/blog/blog.rb for the complete code.)

If you want to write larger applications with Camping, you are encouraged to split the application into distinct parts which can be mounted at URLs on your web server. You might have a blog at /blog and a wiki at /wiki. Each self-contained. But you can certainly share layouts and models by storing them in plain Ruby scripts.

Interested yet? Okay, okay, one step at a time.

Installation

  • gem install camping

Or for the bleeding edge:

  • gem install camping --source code.whytheluckystiff.net

You are encourage to install Camping and SQLite3, since it is a small database which fits perfectly with our compact bylaws, works well with the examples.

Running Camping Apps

The blog example above and most Camping applications look a lot like CGI scripts. If you run them from the commandline, you’ll probably just see a pile of HTML.

Camping comes with an tool for launching apps from the commandline:

Debugging Camping Apps

If your application isn’t working with the camping tool, keep in mind that the tool expects the following conventions to be used:

  1. You must have SQLite3 and SQLite3-ruby installed. (Once again, please see code.whytheluckystiff.net/camping/wiki/BeAlertWhenOnSqlite3 for instructions.)

  2. If your script is called test.rb, Camping expects your application to be stored in a module called Test. Case is not imporant, though. The module can be called TeSt or any other permuation.

  3. Your script’s postamble (anything enclosed in if __FILE__ == $0) will be ignored by the tool, since the tool will create an SQLite3 database at ~/.camping.db. Or, on Windows, $USER/Application Data/Camping.db.

  4. If your application’s module has a create method, it will be executed before the web server starts up.

The Rules of Thumb

Once you’ve started writing your own Camping app, I’d highly recommend becoming familiar with the Camping Rules of Thumb which are listed on the wiki: code.whytheluckystiff.net/camping/wiki/CampingRulesOfThumb