Camping 1.3, the Microframework

Ruby
1

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

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

2

Oh and one last thing. There is an indiscriminate mailing list if you
want:

http://rubyforge.org/mailman/listinfo/camping-list

_why

3

On 2/7/06, why the lucky stiff [email protected] wrote:

== !^! 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.

Wondering… is that a typo or is it really ‘blog_post’ instead of
‘blog_posts’? The default AR convention is pluralized table names.

Jacob F.

4

Hi Jacob,

Wondering… is that a typo or is it really ‘blog_post’ instead of
‘blog_posts’? The default AR convention is pluralized table names.

Is that the AR convention, or is that how AR operates in the context of
Rails, which uses Inflector to translate all those names back and forth
for you?

5

why the lucky stiff wrote:

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.

Is ActiveRecord a requirement?

–
James B.

http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.30secondrule.com - Building Better Tools

6

Quoting James B. [email protected]:

why the lucky stiff wrote:

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.

Is ActiveRecord a requirement?

No more than it is for Rails.

-mental

7

[email protected] wrote:

No more than it is for Rails.

Ah, I see. It does not include its own persistence lib.

Thanks.

8

Seth Thomas R. wrote:

Wondering… is that a typo or is it really ‘blog_post’ instead of
‘blog_posts’? The default AR convention is pluralized table names.

Is that the AR convention, or is that how AR operates in the context of
Rails, which uses Inflector to translate all those names back and forth
for you?

Jacob was right about that typo: it’s `blog_posts’.

AR convention is to figure out the table names from the class names and
vice versa. Camping sticks on the `blog_’ prefix (based on the name of
the module your app is stored in.)

_why