The Camping Framework, Rails Scaffolding, and Dangers of HTML Generation

—Sunday, February 12 2006

Html-Boxers

(Sorry _why, I couldn’t resist a comic!)

The Rails Scaffold and Views

When I was first looking into Rails, one of the things that turned me onto it as a designer is that it understood HTML is meant to be in HTML documents so it can easily be modified by a designer.

When Rails generates a scaffold, or you happen to generate a view by supplying some methods to the controller in script/generate controller it generates just enough code for a developer and designer to get started. In other words, it’s less designers have to rip out in order to create the real interface.

Scaffolding solves two problems. It gives developers a raw interface to interact with as they write their code and it also gives the designer a hint as to what variables are exposed to them in the view and an example to start from in order to work with these variables in ERB. It allows us to do our job effectively with minimal hassle.

Scaffolding views retain their HTML characteristics. While we have to deal with ERB or another template language such as Liquid, this is just a requirement of being a designer involved in software development. The key point here is that html remains in html documents (.rhtml in the case of Rails) for designers to modify. It isn’t buried in the application code inaccessible to us, and it isn’t trying to be replaced by another language.

Rails also has methods you can use in views to generate html. These primarily deal with the generation of forms elements. They are really useful and help to minimize the ruby code which has to be put into the view. For example, the text_field method will auto-populate with the correct value if you are editing an item.

We also have a lot of stuff like date_select, select_time, and many more. The reason these methods are good examples of HTML generation is because they are generating more than just the tag itself and are very specific in nature as to what they do. These tags are not trying to be a replacement for HTML, merely an assistant. Also, if we don’t want to use them, we don’t have too. We retain complete control over the views. If we want to write a form as pure html, we can.

Camping’s Views

There is also another neat little framework written by that crazy neighbor on the Ruby block (no pun intended) Why The Lucky Stiff. _Why created a micro-framework called Camping. It’s very compact and a nice little tool for programmers only. This could’ve been _why’s original intent, if thats the case it’s really unfortunate.

Why is Camping not suitable for a project that involves a designer? Overzealous use of HTML generation. For example, take a look at a Camping view that spits out a list of authors (pulled from one of the examples in the svn repo):

    def authors
        ul.authorList! do
            @authors.each do |author, cmds|
                li do
                    strong author
                    text � worked on: � +
                        cmds.map { |cmd|
                            capture { a cmd.name, :href => R(Show, cmd.name) }
                        }.join(�, �)
                end
            end
        end
    end

Absurd! Camping uses a markup language (also created by _Why) called Markaby or Markup as Ruby. It’s also a nice little tool that has very practical uses, but generating an entire frontend for an application in Ruby isn’t exactly appealing to designers. It’s about as practical as a screen door on a submarine for this purpose.

By doing this you totally remove the possibility of a designer entering the equation. So if your writing an application in Camping, your likely to never get any contributions from a designer.

_Why, we want our HTML! Please give us the ability to use ERB or something similar outside of Ruby files. If I could borrow a quote from Ronnie Van Zant“Gimme back my bullets. Put ‘em back where they belong”.

(Yes, I quoted a Lynyrd Skynyrd song). ;-)