Building Internet applications with Rails is getting even easier as projects like ActiveScaffold and Hobo mature.
Recently, we started working on an internal software project and decided to prototype it in Rails. I’ve messed around with Rails off and on for a year or more and I really enjoy working with it. But in a way, Rails is it’s own worse enemy.
Why? First, because Rails elevates your expectations for what a framework is supposed to do. Once that happens — and your eyes adjust to the dazzle of running scaffold that first time — you’re tempted to ask questions of your software infrastructure that might not normally have occurred to you.
This is exactly what happened to me as I was sketching out how many custom has_many :through code blocks we would need for the app we were writing. In it’s own way, exactly the same type of nonsense that needed to be written 10 years ago. Since I’m not a software developer by trade any more, I tend to look for ways to cut corners. For apps of a certain size, Rails still looks too much like programming for someone as lazy as myself.
Having already gone through Scaffold Withdrawal, what I need, I thought, was a really smart (or dynamic, or something) scaffold. So I went looking and I’m pretty pleased at what I found.
ActiveScaffold
The first thing I came across was ActiveScaffold. ActiveScaffold is a really nice product that looks at your ActiveRecord associations and builds CRUD functionality for your controllers on the fly. I liked ActiveScaffold but it seems best suited as a tool to get quickly get a data in/out or reporting app up and running. You control ActiveScaffold’s input and output via configuration files, which I found a bit confusing, and it’s a little AJAX heavy for my tastes, but if you’re looking for (rapid prototypes on data-heavy apps, check it out.
Ultimately, for what we were doing, ActiveScaffold wasn’t a fit so I kept digging around. And that’s when I came across Hobo. (Via a link on the ActiveScaffold site, actually.)
Hobo
Hobo isn’t really a scaffold — though it may seem like that at first blush — really, it’s an application builder extension to Rails. In addition to creating index, show, new, create, edit, update, and destroy controllers on the fly for your ActiveRecords, Hobo also has a really nice markup language called DRYML — get it? DRYml. DRYML is nice because it isn’t just an alternative to render :partial, it’s a full-blown tag-rendering system with a ton of potential.
But what really sold it for me was the users.
There’s a point in the first of the Hobo screencasts that Hobo creator Tom Locke is walking through creating controllers and models and says something like, “And we don’t need to create a user model because Hobo has the concept of the user built in.”
I had to rewind that and listen to a few times.
Hobo has a user and permission system baked in that allows you very easily apply user credentials to any model in your app. And since it’s all just Rails, you can easily extend it if needed. I really love this feature.
Hobo is an excellent extension to Rails that not only gives you a number of shortcuts when building Internet apps but also makes a really nice markup language available your views. If you’re working with Rails, Tom’s work is definitely worth checking out.
However, there are a few caveats.
Hobo is very young. If you aren’t familiar with Rails, I wouldn’t try to dive too deeply, into Hobo. The docs for Hobo, are pretty thin and without a Rails background, you’re going to run into tough spots. Hobo also doesn’t support has_one. This will most likely get built but until then you can work around by writing custom code or with a belongs_to hack. But even with these drawbacks, I think Hobo merits a look.
