Folks, thanks to Domizio’s great work, HoboFields is ready to try out with Rails 3. Here’s a quick guide to getting it installed and running the migration generator. You’ll need git to grab the latest code, as nothing has been released as a gem, but apart from that you won’t have to do anything too technical. Please note, Rails 3 RC2 just dropped today, but right now we’re still on RC1, so please make sure you have that version of Rails installed if you want to try this out.

OK, let’s grab the code:

git clone http://github.com/tablatom/hobo.git

The Rails 3 work is happening on the cunningly named rails3 branch, so you now need to

cd hobo
git checkout origin/rails3

Next, we use Rake to generate and install the gems for HoboSupport and HoboFields.

cd hobo_support
rake install
cd ../hobo_fields
rake install

That’s it! We’re ready to try a Rails 3 app with HoboFields. Assuming you have Rails 3 installed, use the new syntax for the rails command to create a new app:

cd somewhere/for/your/test/app
rails new test_hobofields
cd test_hobofields

Now, the way to add a gem to a Rails 3 app, is to add the gem to Bundler’s Gemfile. Edit that file, and add this line, at the end:

gem 'hobo_fields', '1.3.0.pre1'

If you now run

rails generate

You should see two Hobo generators listed in the available generators. Let’s create a Hobo model (note the nice new namespaced generator syntax).

rails generate hobo:model book name:string description:text

You can see the fields block has been added to the normal model template if you look at app/models/book.rb:

class Book < ActiveRecord::Base

  fields do
    name        :string
    description :text
  end

end

Now, let’s watch HoboFields work its magic and migrate the database for us.

rails generate hobo:migration

At the prompt, choose “m”, then give the migration a name. If everything is going according to plan, the local SQLite development database should be migrated to include the books table. We can check at the SQLite prompt:

rails dbconsole

Then at the SQLite prompt:

.schema

You should see

CREATE TABLE "books" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "name" varchar(255), "description" text);
CREATE TABLE "schema_migrations" ("version" varchar(255) NOT NULL);
CREATE UNIQUE INDEX "unique_schema_migrations" ON "schema_migrations" ("version");

Score! And did you notice? Domizio even gave us a colored prompt in the migration generator. Too much : )

Domizio is going to let us know how he’s getting on via some short posts here on the blog. He just sent me his first thoughts, so over to Domizio:

Porting Hobo to Rails 3

The new Rails 3 compatible version of Hobo is on the go. It has been 15 days now that I am involved in the project, and it looks very challenging. Rails 3 introduces a lot of improvements, but also a lot of changes that inevitably break the legacy code. Hobo is not an exception: it is deeply interacting with the Rails internals, so the last version got deeply broken as well.

I can only guess the huge amount of work that it will take to make it work, but the result will absolutely be worth the effort: thanks to Rails 3 the new Hobo will have less code, less monkey patching and more efficiency and flexibility.

Hobo becomes a Rails 3 engine.

Thanks to rails 3 engine capability a lot of code has moved to better places and will be loaded at a better time. All the patches to the frameworks are loaded right after the framework with ActiveSupport.on_load hooks. All the code that needs reloading in developer mode has its own place to live in the config.to_prepare blocks. The programmer will have more choices to configure Hobo internals with the config.hobo.* configuration variables, the code will be more organized and easier to maintain.

New routes system for Hobo 1.3

The old ModelRouter has gone: it was drawing routes directly. The new system generates its own roues file and adds it to the routes_reloader.paths, so no monkey patching is needed anymore. The hobo_routes.rb file may be analized by the programmer that can eventually override any route in the regular routes.rb file.

I’ve got a few other things Hobo related that I hoped to blog about but aren’t ready yet, but there’s nothing stopping me from using this blog to point out tools that will make your Hobo experience better, is there?

Most of the Hobo and Ruby on Rails community uses git for version control. Git is awesome, but there are two common pain points: its learning curve, and submodules.

I won’t go into the problems with git submodules here. If you’ve got a small project with only one developer and you never need to modify your submodules, you’re unlikely to run into problems, but as you add developers and start modifying the modules, hassles quickly creep in.

In the past, when you added a plugin to your project, you basically had two options: copy the files into your project with script/plugin or link the files in using git submodules.

Now you can get the best of both worlds. With git subtree you get the behaviour of a copy, but you can still easily update the plugin and even extract changes to the plugin to push the changes upstream.

For instance, to add Hobo as a plugin to your project:

git subtree add --squash --prefix=vendor/plugins/hobo git://github.com/tablatom/hobo.git master

You can then update the plugin with:

git subtree pull --squash --prefix=vendor/plugins/hobo git://github.com/tablatom/hobo.git master

If you make changes to the Hobo in your app, you can extract them and send them to us with:

git subtree split --prefix=vendor/plugins/hobo --branch hobo-master
git push git@github.com:someuser/hobo.git hobo-master:master

(Replace someuser with your github username). And then send us a pull request.

Git subtree is not yet part of git itself, but hopefully it soon will be. Even if it does not, it isn’t doing anything crazy or unorthodox to your repository, so I wouldn’t worry about using it.

Two other alternatives to git subtree are Braid and Piston. They use similar strategies under the hood. However, I’ve found git subtree to work better for me.

The actual interview was quite a bit longer than the version that got published, and the full version is probably of interest to anyone interested in Hobo, so I’m posting it here in full.

How would you describe Hobo in a few words?

Hobo is a collection of extensions to Ruby on Rails designed to make coding Rails apps even quicker and easier than it is already. We’re taking ideas that Rails pioneered, like convention over configuration, and pushing them much, much further.

What led you to develop Hobo?

It started pretty much as soon as I started learning Rails, back in 2006. I quickly found that I was extremely productive in Rails, except for the view layer. I had been experimenting with tag languages since as early as 1995 (browsing with Netscape version 1!) and had some ideas stored up. I was learning Ruby at the same time, and as I started experimenting, I quickly realised what a great language it is for this kind of thing. I was hooked. The Hobo project took off from the momentum that Ruby gave me.

Who is using Hobo? How big is the community?

We’ve had over 2,000 downloads of Hobo 1.0 and we’re approaching 500 members of the mailing list. It’s growing pretty quickly at the moment. As for who they are, we’ve had all sorts, from hobbyists to NASA. It’s especially popular with people that would love to create a Rails app but are a little intimidated by how much they have to learn in order to get to their finish line. With Hobo they can see that their goal is within reach.

I’m very happy to say that the Hobo community is very friendly. Newcomers are always welcome, and no one will tell you to RTFM!

What kinds of application is Hobo used for? Why would someone choose Hobo over Rails? Is Hobo useful for developing enterprise/business apps, or is it more for individuals making personal sites? Would professional web developers use Hobo?

Hobo can really be used anywhere that Rails can. The sweet-spot is for smaller projects and prototypes – that’s where the speed-up is most noticeable. With the professional folk, some love the power it gives them, and some seemingly prefer to do things at a slightly lower ‘hands-on’ level. Actually we’ve worked very hard to make sure you can always go ‘under the hood’ and can change anything that you could with regular Rails, but there is a learning-curve to be surmounted before you get to that point.

How does Hobo differ from other similar tools which are available, such as ActiveScaffold or Streamlined (or even make_resourceful and other REST controller frameworks)? Is Hobo just another scaffolding framework?

In my opinion Hobo is entirely different from these tools. I’ve written about this several times over the history of the project because obviously there’s a perceived similarity. Scaffolding frameworks are very useful in situations where rough-and-ready is good enough. For example, as a stop-gap while you’re working, or in an admin site that your public users won’t see. Hobo is for your whole app. You can start with the out-of-the-box UI, which is already closer to a usable site than you might expect, and from there you can gradually tweak anything and everything until you have exactly the user-experience you’re after.

Your site features two books devoted to Hobo. Why does Hobo require two books’ worth of documentation? Is the learning curve steep?

Hobo is a big project. There’s a lot to learn but you only need to learn a little to be up and running and productive. The more particular you choose to be about fine-tuning your app, the further along that learning curve you’ll need to go. In practice it tends to be the people that build several Hobo apps that decide to learn the details.

How many plugins are included in Hobo? Is there more to Hobo than the three plugins HoboFields, HoboSupport, and DRYML? What are the external dependencies? Does Hobo require any native extensions? Can I run it under JRuby?

Actually DRYML still hasn’t been separated, although Bryan Larsen has pretty much done the work now as part of his efforts to support Rails 3. So we have HoboSupport, HoboFields, and Hobo itself which includes DRYML. We rely on will-paginate for pagination and that’s about it. There are no native extensions, and it runs fine under JRuby.

Do we really need another markup language? What does DRYML do for the user that, say, partials in Rails wouldn’t?

DRYML is the part of Hobo that I’m most proud of — I believe it brings some significant and important innovations to the table. It’s main strength is allowing view-code fragments to be packaged up for re-use, without sacrificing flexibility down the line. I think any discerning hacker who’s written a lot of Rails view code knows that we need something better. Projects like Seaside (for Smalltalk) and Erector make low-level languages like ERB and HAML look very primitive.

The important idea in DRYML is nested parameterisation. Imagine method A calls method B which calls method C, and in your code, which is using A, you realise you need to tweak a parameter to C. If that parameter is not exposed by both B and A in turn, you’re sunk. With DRYML you can “drill down” and add that extra parameter to C. In regular code this would be total chaos, but in view-code where all you’re ever doing is generating fragments of HTML, without side-effects, it works wonderfully. You can remove that breadcrumb link, inside that latest-news widget, inside your blog’s index page, without ever having to repeat any of the intermediate HTML code.

If a developer uses HoboFields to specify fields in the model classes, how does HoboFields maintain compatibility with ActiveRecord, which is looking to create those fields by querying the database? Wouldn’t this break ActiveRecord? What are the advantages and disadvantages of moving away from Rails’ philosophy of generating the model dynamically from the database columns?

It doesn’t break any aspect of ActiveRecord. ActiveRecord still creates the fields by interrogating the database. The fields block in a HoboFields model is used by our migration generator. Originally it wasn’t used at runtime at all. The migration generator essentially does a ‘diff’ of your database and your field declarations, and writes both the up and down migrations for you. So for example, if you want to rename a field, you literally go to the model and rename it, and then run the migration generator. Job done. ActiveRecord carries on as normal, taking the field name from the (now updated) database.

Once that was working we realised that the fields block was a great place to add a few more conveniences, like some nice shorthands for validations (e.g. name :string, :required).

I’ve honestly not encountered any down-sides at all. There’s really no need for anyone to write migrations by hand any more.

If I add a new field to a model, HoboFields creates a new migration to add a column to the database. How does it keep track of what additional migrations it needs to create? Isn’t this process fragile?

There’s nothing to keep track of. You run the generator, it creates a migration that will bring your database into line with your code. Once you’ve run that migration you can sanity-check by running the migration generator again and it will say “Database and models match – nothing to change”. It’s rock-solid. The one issue that is a challenge for any tool that attempts this is that you can’t tell the difference between an add/remove and a rename. For example, the migration generator sees a column in the database called ‘name’ that’s missing from the model, and a field in the model called ‘title’ for which there is no column. Did you remove the ‘name’ field (and hence want all the name data to be dropped) and add a new one called ‘title’, or did you rename ‘name’ to ‘title’? It’s impossible to tell. One solution is to require the developer to include some kind of hint in the source code, which could later be removed, but that’s clunky. In the end I realised that there was a simple solution – just ask! So the migration generator is interactive: is this an add/remove or a rename. It only asks when there is ambiguity.

What are HoboFields Rich Types? What kinds of types are there?

A rich type allows you to capture higher level information about your data, such as “this is an email address”, or “this is Markdown formatted text”. You know that information when you are coding your model, so it’s a shame not to capture it. Doing so allows you to do some nice tricks, like rendering Markdown text correctly as HTML without having to do a thing in your view code, or getting validations for email addresses. These things happen automatically as soon as you tell HoboFields the type of your fields. You can very easily add your own rich types.

Does Hobo add tools for building AJAX applications over and above what’s provided with Rails?

Yes. In Rails, if you have a fragment of a page that needs to be updated via AJAX, you have to factor that out into a partial – a separate template file. Sometimes they are ridiculously small and you can end up with unmanageably large numbers of them. DRYML has the concept of a part, which is a section of your template that is marked as something you want to update. There’s no need to go to a separate file. Even better, in many cases Hobo knows how to update the part for you. You can just annotate, say, an ajax form or button, with update="foo" where ‘foo’ is the name of your part, and it just works — the page is updated according to the new state of the database after the ajax operation is complete. To be honest that’s one of the more magical features in Hobo — perhaps too magical for some people’s tastes. But it’s totally optional.

What makes the 1.0 release a milestone release?

It means we stopped adding features and focused on documentation and stability until we felt ready to say, OK, all sorts of people can feel comfortable using this now. We’ve also made a commitment to not make major breaking changes without a grace period of warning messages, very much as with Rails.

How do you see Hobo evolving after 1.0?

To be honest I feel that this is now up to the community. There are a million ideas to explore, but which ones get done depends on what people want, and what people are going to contribute. We’ve just had a fantastic contribution to the internationalisation support, and to be frank that wasn’t on my radar at all. It’s great to see the project gain it’s own momentum like that.

*The Hobo site says that Barquin International sponsors Hobo. Was Barquin involved with Hobo from its inception? What does Barquin’s support enable that you wouldn’t have if you were simply an open-source project without funding? *

The project had already been going for about two years when Owen Dall of Barquin spotted us and decided to get on board. To be clear, we’re not talking about VC-like funding here, with a long line of zeros. Barquin supported myself, and later Bryan Larsen to work on the code and still be able to pay the rent. Progress accelerated a great deal compared to fitting the project in on the side. I’m married with kids so the days when I could stay up all night working on a hobby are long gone. We also learned a lot by watching a company picking up Hobo and training their team. We were able to make the learning curve a lot more pleasant as a direct result of that experience. More recently, the project to create the Hobo books came entirely from Barquin. Some of my words were used, from documentation I’d written already, and for that I got authorship credit, but in truth the books happened entirely because of Owen and Jeff over at Barquin. The community has benefited enormously of course, so all in all we’re extremely grateful.

gem update hobo

There are two speedups: one that reduces the number of database accesses by Matt Jones and one that speeds up compilation of DRYML by Petteri Räty.

If you’re interested in the details of what got fixed, take a look at the commit log on github.

Thanks very much to everyone who contributed!

Meanwhile work continues on Hobo 1.1. Watch this space : )

Go get it!

gem update hobo

or

gem install hobo

I for one never thought it would take that long! But then the project has changed such a lot. In the early days we thought the automatic UI provided by Hobo would be a good starting point, but not much more. As we went on we noticed more and more patterns in web UIs, patterns we could capture in Hobo. As a result you can now get a surprisingly usable app for almost no effort beyond creating your models.

Of course from there you can customise things to your heart’s content – that was the goal right from the start and it hasn’t changed.

Along the way we added some killer features too. Writing migrations by hand is pretty much a thing of the past in Hobo apps, since we added the migration generator (also available with the rest of Hobo!). Hobo’s lifecycles make it so much easier to implement multi-step processes, you get a UI to your lifecycles with little or no code, and there’s even support for secure links in email messages (for implementing things like forgotten-password and account-activation).

We’ve also put a huge effort into getting Hobo documented. We’ve built a community driven documentation site – cookbook.hobocentral.net, which is also the home of the extensive manual. There’s a new introductory screencast. Oh and there’s two books available to download, and a third on the way!

Perhaps more importantly than any of that, there’s a thriving and very friendly community. One of the most consistent comments we get from developers is how much they appreciated all the help and support they got while building their first Hobo app. Be sure to check out all the cool apps they’ve built.

For myself personally, and on behalf of the whole Hobo community, a huge thank-you goes out to all the people that helped us get here. In the beginning there was Line Learning & Communications and Jiva Technology, who contributed enormously by choosing Hobo for major projects, and of course my coding partner on those projects and the early version of Hobo, James Garlick. James’ keen sense of aesthetics has had huge impact on the design of Hobo, inside and out. We had a good laugh too!

Today of course there’s Owen Dall, Ramon Barquin, and the team at Barquin International. Owen spotted us at an early stage. He saw in Hobo a vision for the future and took a big bet on us. Barquin’s sponsorship has made Hobo 1.0 possible. Thanks Owen! There are too many people in the open-source community to thank individually, but a mention has to go to core contributors Matt Jones and Bryan Larsen — as you know, it’s been you guys much more than me that have polished things off, fixed the bugs, and got us to 1.0. And in the background all along, unseen by most, is my business partner, coach, cheerleader, agony-uncle and general strategist, the one and only Mr. Nigel Powell. Well done everyone!

At this point it is customary to say “and this is only the beginning!”. In this case however, it’s not just an up-beat signing off remark. I’ve not actually been committing loads of code to Hobo in the last few months while Matt and Bryan have got us to 1.0. The reason is, I’ve been in the back room, quietly tinkering, tweaking, experimenting, honing. The next chapter in this story could just be a game-changer. Stay tuned.

A large amount of the effort between the last two releases has gone into testing and into the documentation.

Here’s the changelog:

#604:

The new input-many introduced in 0.9.103 had issues with >10 elements, several issues running with IE7 and an issue with its javascript callbacks.

#537:

x._?.to_s now returns nil rather than a blank string

#592:

If you previously had a snippet such as this:

<table fields="this, date, account.login">
  <login-view:>
    ...
  </login-view:>
</table>

You now have to use:

<table fields="this, date, account.login">
  <account-login-view:>
    ...
  </account-login-view:>
</table>

The same change has been applied to <field-list>

#568:

hobo_index now supports the :scope option

See also the git log

If you are on Rails 2.3.5 and are running Hobo as a plugin, please check out bug #574 for a workaround you need to apply to your Rakefile.

Bugs

This release fixes a couple of serious bugs: 565 and 567.

Input-Many & has-many :through

The <input-many> tag in Rapid has been replaced with a version ported from the <hjq-input-many> tag in Hobo-JQuery. This brings the following enhancements:

• it supports 0 length associations
• input-many’s may be nested inside of other input-many’s
• it allows the (+) and (-) buttons to be customized
• it provides a default for the item parameter
• it copies from a template rather than cloning the current item and clearing it
• the template may be overridden
• id’s of textareas and selects and other non-input’s are adjusted properly
• classdata for inner elements updated

The new <input-many> tag differs from <hjq-input-many> in that:

• it’s written in prototype.js rather than in jquery
• it doesn’t have the delayed initialization feature
• the name of the main parameter is default rather than item
• hjq-input-many allows you to provide javascript callbacks. input-many fires rapid:add, rapid:change and rapid:remove events that can be hooked.

You will have to ensure that your hobo-rapid.js and clean.css files are updated in your application.

Changes

There were other minor bugs fixed. See the github log

You know, one thing I’ve significantly improved in Hobo since taking over maintenance from Tom has been the test suite. Regardless, I seem to consistently require brown paper bag releases, but I don’t see any of them in Tom’s history.