Hobo is a plugin for Ruby on Rails that brings a number of extensions—some small some large—to Rails application development. The common theme to these extensions is rapid development.
Like Rails itself, Hobo encapsulates a number of opinions about web application development. The opinion that is most central to Hobo is this: we have found that there is a great deal of similarity from one web application to the next. Much more similarity in fact, than is supported by today’s frameworks. We would rather implement this stuff once.
Of course this approach is common to all frameworks—everything that Rails provides is there because many or all web applications will need it: database connectivity, session management, working with HTTP, etc. etc. The difference with Hobo is that we are trying to take this idea to a much higher level than is normally expected from a web framework. The ultimate goal is: don’t program your application, just declare it.
Because Hobo might do a lot more than you have come to expect from a web framework, it can be difficult to get a handle on what Hobo actually is. For example, it seems that a lot of people see Hobo as the same kind of tool as something like Active Scaffold. It is not. The only way to really get an understanding of how Hobo can speed up your web application development is to use it. But to help you get started, here’s a brief summary of the main features you’ll find in Hobo.
Model layer extensions
In a Hobo app, you typically add the declaration
hobo_model to all of your models (although you don’t have to). This gives your models a bunch of extra smarts:
Lifecycles :: REST is fine and dandy, but real applications need more than that. Define a state machine on a model and Hobo will add support for it in your controllers and views as well.
Migration generator :: A hobo model has the declaration of the database fields inside the model source code. Using this information, Hobo can generate complete migrations for you, including the down migration. You can freely add, remove and rename fields and entire models. Hobo will compare the state of the database with the state of your source-code and create a migration to bring the database up to date.
Rich field types :: When you declare your field types in Hobo, you are not limited to the basic SQL types. Hobo extends the default set with richer types like HTML, markdown and email-address. You can also add your own. The view layer knows how to render these types properly, and the model layer knows how to validate them.
Permission system :: Hobo uses a model-centric permission system. On each model you declare exactly which user is allowed to do what. The controller layer will only allow creates, updates and deletes which you have permitted. The view layer will also use this information in various ways, e.g. automatically removing fields from forms if you do not have permission to change them.
User model :: The concept of a user model is baked-in in Hobo. If you declare any model as a
hobo_user_model, you’ll automatically get all the database fields and methods to give you authentication (log-in), including ‘remember me’ functionality.
In a similar manner to the model extensions, you will typically add the declaration
hobo_model_controller to every controller in your Hobo app. The features this brings in can eliminate a great deal of controller layer programming.
Auto-actions :: Just declare
auto_actions :alland you’ll get default implementations of all the ‘standard’ controller methods: index, show, new, edit, create, update and destroy. You’ll even get actions to handle collections that your model provides (e.g.
new_topicon a forum resource). These actions can be extensively customised.
Filtering, searching and sorting :: Publish parameterized filtering and searching functionality in a snap.
Sub-sites :: Web apps often need different “sub sites” for different kinds of user, the typical example being the “admin” site. Just create a directory in app/controllers, and Hobo will set it all up for you.
Automatic routing :: If you want to stick with conventional REST-style and state machine routes, all the information needed to configure the routes can be found in your controllers. Hobo has an automatic router that inspects your controllers and does the job for you.
The view layer is where the real Hobo magic lies. In fact it was the experience of spending 80% of development time in the view layer that led to the creation of Hobo. The vast majority of the effort behind Hobo has gone into the DRYML template language.
DRYML :: A tag based template language built. While the idea of defining your own tags is not new, DRYML has a unique take. Defining tags is extremely simple and lightweight, and, more importantly, DRYML has a very powerful mechanism for the customising the output of a tag each time it is used. This gives a very powerful combination of high-level re-use along with “context-over-consistency” tweaks. DRYML also features an implict context that makes you’re view code poetically brief.
Ajax mechanism :: DRYML makes it very easy to dynamically update parts of your page. There’s no need for separate partial files - just mark the part you want to update, and DRYML will automatically extract it. When used in conjunction with Hobo Rapid, Ajax becomes so easy it’s often less work than a non-ajax approach.
On top of these extensions to the three MVC layers, Hobo provides some bits and pieces that help tie it all together.
Generators :: Rather than generate ‘normal’ Rails classes and then upgrade them with Hobo features, Hobo provides custom generators that create source-code that’s ready to work with Hobo.
Ruby extensions :: Hobo’s answer to Active Support - a grab bag of useful Ruby extensions to make your coding a little easier.
Edit this page