We felt lucky, the 20 of us from Copenhagen Ruby Brigade who had taken the time to show up for the third gathering of Rails enthusiasts in and near Copenhagen, this time hosted at my company; Kraftvaerk. Not only had open source guru and Ruby for Rails author David Black decided to join us for the evening, having taught a workshop in Malmö two days before; but when a little later no other than our own Rails creator and community front figure David Heinemeier Hansson (DHH) stepped in through the door, we started wondering whether this was really just a humble user group meeting – or RailsConf Copenhagen!

Not only did DHH willingly answer all questions we could come up with, he also showed us his demo from his keynote at RailsConf in London, including some pieces that hadn’t been ready for the conference, and which we were probably the first to experience. It’s hard to take notes of guy writing code live on the screen, especially when he moves away from the planned demonstration into “I’ve never tried this before, but let’s see if it works!”, but I tried, and this article is my write-up of DHH’s answers and demos.

HAML
DHH gave a quick sample of HAML - HTML Abstraction Markup Language – a template language for rendering beautiful XHTML in an easy to read and write way, created and announced by Hampton Catlin at RailConf Europe 2006, and quickly acknowledged by DHH:

%html
	%body
		#person
			#details
		.phone_numbers
	%li = list_of(:people) &:names

What’s cool about HAML, DHH said, was that it kept you DRY, even when you are writing HTML. The % is used for normal tags, the # creates div tags with the given id and the . creates div tags with the given class. It’s even possible to mix in Ruby code and for example create a list.

Internationalization
Being in a room full of Danish programmers, it was only that natural that internationalization came up – especially since Jesper Rønn-Jensen has been working on a localization plugin, and as Morten Christensen pointed out; shouldn’t 5 or more plugins for internationalization indicate quite clearly that the Rails community craves unified support implemented in the core?

No, DHH answered, from the Core Team’s point of view, this means that people want to support and implement internationalization in a lot of different ways, and that there is no universal solution that will make everybody happy. Even inside the Core Team people can’t agree how it should be done. Although, DHH added, I can’t rule out that the 37signals needs internationalization, is the day that Rails get it.

Better scaffolding
Scaffolding has lured a lot of developers into the wonders of Rails, but really, DHH said, it has always had a lot of strange limitations, which made it nearly useless for doing any real stuff. Scaffolding continues to be primarily a teaching tool, but the new scaffold_ressource command makes a lot of things right, that was wrong in the old kind of scaffolding:

  • Old scaffoldings required you to have a table created for the object you where creating scaffolding for – now a migration file that will create the table is automatically adde.d
  • The old scaffolding let you choose the controller name – now you only get the specify the name of the model, and the controller is automatically added with correct pluralization.
  • Inside the controller, the old scaffolding had a list action, but no index – now it’s the other way around, since the index is the correct action to use.
  • The views generated by the old scaffoldings was almost useless, since they just looped through the columns in the table – now, each actual column gets HTML created for it.
  • Aside from that, the scaffolding views are still ugly – by design!

In summary; the new scaffolding generator lets you create RESTful scaffoldings that you can actually build on top of, and all with a command like this:

./script/generate scaffold_ressource post title:string created_at:datetime body:text

Any action can respond in any kind of format
By adhering to the Simply RESTful conventions and using the respond_to method, we can make our objects in any format we desire, without having to write separate actions for each format. DHH was building up his classic weblog application, and wanted to implement an XML representation of the Post object that could be consumed by an external application:

def index
	@posts = Posts.find(:all)

	respond_to do |format|
		format.html
		format.xml { render :xml => @posts.to_xml }
	end
end

This code actually enables us to access the list of all posts in the ordinary RHTML format from the url /posts, but if we want the XML representation of the same list, we just add .xml; like this: /posts.xml. This doesn’t just work with XML, in fact it works with any kind of extension you add support for in your actions, as long as you also remember to add it’s mime type in environment.rb, as DHH had to do to support the CSV format:

# environment.rb
Mime::Type.register("text/csv")

Further, DHH recommended his plugin Resource Feeder for easy support of ie. RSS using the method render_rss_feed. Another cool thing added is the auto_discovery_link_tag method, which renders the appropriate tag to ensure that the RSS icon is shown in Firefox, Safari and IE7.

ActiveResource working like a charm
While no surprise to all the lucky ones that attended RailsConf Europe, I enjoyed seeing the visions for ActiveResource DHH explained at the conference in Chicago, being now brought to life and working like a charm. By letting a model inherit from ActiveResource::Base instead of ActionRecord::Base and giving it a url to feed of, DHH demonstrated that you can treat objects in an external API exactly like the ones in your own database. And not just reading part of CRUD, the whole package. Sweet!