February 12th, 2006

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

9 comments on 1297 words

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):

1
2
3
4
5
6
7
8
9
10
11
12
13
14


    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). ;-)

Discussion

  1. eric eric said on February 12th

    _why created Camping as a stunt (the whole “consistently stays at less than 4kb of code” thing). It is also a fairly simple and useful compact framework.

    I don’t believe he ever intended to replace Ruby on Rails with it, or anything of the sort. As such, it seems a little absurd to be complaining that it isn’t very Designer Friendly.

    We could also point out that Try Ruby is not very Designer Friendly, but that isn’t terribly relevant either.

    It seems to me that by the time your designers are not developers, you’ve likely grown out of Camping.

  2. Justin Palmer Justin Palmer said on February 12th

    Hi eric,

    I knew his intentions were not to replace Rails. Although I picked on _why’s Camping as an example, the point of the article was to discuss html generation abroad.

    Camping is nice, and has very useful and practical situations where it would be better than Rails, however you’d have to work very closely with a developer in order to create a UI for a Camping application.

    I don’t quiet understand your Try Ruby comment. I could argue that my alarm clock isn’t very shower friendly, but it wasn’t designed for water so we won’t go there. ;-)

    Camping has a view, a frontend to interface with a user, one example is even a blog so it’s natural that I raise the point about designers.

    Markaby is very useful, but it also can be abused by developers who decide to generate full html documents with Ruby code.

    I like what _why has done with Camping with the exception of generating full html documents in Ruby.

  3. why why said on February 13th

    Wooyeah to the playful punches of the pugilists!!

    Oh, hey, cool, glad you like Camping. I like your blog, for sure. Re: the moral dilemma at hand—I can’t really justify what I’m doing, and have no idea whether it’s right or wrong. That debate’s been had on Son of WebPage. I guess this is relevant to Try Ruby, since it’s used in the popup chapter.

    But, hey now, what’s the big idea shielding your designers from Ruby? You’re just going to keep all the life-giving substance to yourself I guess? I mean this is a lovely language for humans all.

  4. Michael Daines Michael Daines said on February 14th

    I don’t understand why everyone is so hot on HTML. I hate it!

  5. Justin Palmer Justin Palmer said on February 15th

    _why, we’d have a shortage of designers if they discovered Ruby!

    Michael: HTML is a necessary evil that allows designers and developers to share some common ground.

  6. andré camargo andré camargo said on February 20th

    I was thinking: there are some way to put ALL (I said: ALL) design freaknesses on CSS and leave on (X)HTML only the structure (something like the representation of a wireframe)?

  7. Xian Xian said on February 22nd

    I’m a designer before a programmer, and I agree with you completely. HTML is quite useful.

    One of the things I like about Markaby though is that when used with Rails it can be used interchangeably with normal .rhtml templates. So rhtml can be used for the layout and the areas it makes sense, and you can call markaby partials for the html that is better generated. And there is html that is much better generated.

  8. Mr eel Mr eel said on March 7th

    The problem is that looking at the markby code doesn’t give any clues to what the final HTML will look like.

    Even as Ruby code, it doesn’t look all that readable to me. HTML should stay as HTML, because that is the most simple solution.

  9. David David said on August 14th

    I think markaby is more readable than html is because of the use of closures.

    html do { ... }

    when reading a webpage source means to me “create an HTML body and its contents is ….”

    its easier to read ellipses than closing html tags everywhere. You have fewer characters to read and can absorb more of the content/layout better.

Sorry, comments are closed for this article.