From: why the lucky stiff <ruby-talk@...>
Date: 2006-02-08T14:46:52+09:00
Subject: [ANN] Camping 1.3, the Microframework

Good people of the town: Maybe some of you are interesting in the 
continuing story of Camping.  If not, I understand, these are sensitive 
matters, best wishes.

Camping is a small framework designed to mimick Rails, but weighing in 
3.9k.  A full explanation can be had at the documentation site:

  http://camping.rubyforge.org/

= New in Camping 1.3 =

If you've used previous versions of Camping, I would _highly_ encourage 
you to examine the list of changes below, since this will affect how you 
build Camping apps.  To those you who've been following development 
gems, there isn't anything new as of two weeks ago.  Who knows, you 
might want to read anyway.

== !^! Warning -- ActiveRecord Table Prefixes !^! ==

This is probably the biggest part of Camping which will trip people up.  
Since mounted Camping apps are designed to share a database, I'm using 
table prefixes to prevent name clash.

If you have a model class called Blog::Models::Post, the database name 
will be 'blog_post'.  The top-level module name is used.

If your model class is in Camping::Models::Post, prefixes won't be used, 
it's just 'post'.  The reasoning is: if you're placing your models right 
in the Camping module, you probably haven't designed it to play friendly 
with other apps.  (See Camping.goes below for more on playing nicely.)

Since table prefixes are used, you'll also need to use the full table 
name in your IDs:

  blog_post.id => blog_post_id
  blog_user.id => blog_user_id

Unless you set up the `foreign_key' property and such properly in the 
models.  See 
http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html 
for instructions.

== bin/camping ==

Camping now comes with a launcher.  Once your gem is installed, launch 
any Camping application with:

  camping your-app.rb

You will need to install SQLite3 and its gem for this to work: 
http://code.whytheluckystiff.net/camping/wiki/BeAlertWhenOnSqlite3

The database will be stored in ~/.camping.db.  On Windows: 
$APPDATA/Camping.db.

== Camping.goes ==

Since you may choose to mount several Camping apps at once and store 
them in a mutual database (for possible cross-pollenation), the 
Camping.goes mechanism will copy the Camping framework into a new module 
for hacking:

  require 'camping'
  Camping.goes :Blog

  module Blog::Models ... end
  module Blog::Controllers ... end
  module Blog::Views ... end

== Camping.create ==

Every database-dependant Camping app should have a Camping.create method 
which checks to see if the database tables are created.  If not, run the 
schema.

An example on the wiki: 
http://code.whytheluckystiff.net/camping/wiki/GiveUsTheCreateMethod

== Camping.run ==

The Camping.run interface is used to interface with the web server.  
Traditional CGI environments can call Camping.run without arguments.  
Web servers which have nice cushiony Ruby extensions can call 
Camping.run with arguments:

  controller = Camping.run(request, env)

Examples of working with a bunch of different web servers is in the 
postambles collection: 
http://code.whytheluckystiff.net/camping/wiki/PostAmbles

== Rails/PHP-style query string ==

The query string: ?post[user]=_why;post[id]=2

Will be available as a hash at @input.post in your controllers.

   module Blog::Controllers
      class Save
        def post
          @post = Post.create(@input.post)
        end
      end
   end

== Luxurious RDoc ==

The RDoc is now a nice multi-page, non-frame RDoc.  Try it out: 
http://camping.rubyforge.org/

= Lastly: Installation =

You may install like so:

  gem install camping

Or, if you'd like to follow the bleeding edge gems:

  gem install camping --source code.whytheluckystiff.net

_why