Rails 2.3: Templates, Engines, Rack, Metal, much more!

Rails 2.3 is finally done and out the door. This is one of the most substantial upgrades to Rails in a very long time. A brief rundown of the top hitters:

  • Templates: Allows your new skeleton Rails application to be built your way with your default stack of gems, configs, and more.
  • Engines: Share reusable application pieces complete with routes that Just Work, models, view paths, and the works.
  • Rack: Rails now runs on Rack which gives you access to all the middleware goodness.
  • Metal: Write super fast pieces of optimized logic that routes around Action Controller.
  • Nested forms: Deal with complex forms so much easier.

And that’s just the tip of the iceberg. We’ve put together a complete guide for the Rails 2.3 release notes with much more information. Be sure to checkout the section on what was deprecated when you’re ready to upgrade your application.

You install 2.3 with (the final version is marked 2.3.2):

gem install rails

If you’re running on Passenger, be sure to upgrade to 2.1.2 as well. Rails 2.3 doesn’t run on older versions of Passenger!

We hope you’ll love it.

This Week in Edge Rails

March 6, 2009 – March 13, 2009

Things have been pretty busy on the development side since the release of Rails 2.3 RC2. The core team has been making a serious effort to review all of the open bugs and patches with an eye towards getting us a solid release. At this point, the bar for new features is set fairly high, but even so, there have been an incredible 94 commits in the week since RC2 – mostly fixes to ensure expected behavior and stability. Here are some of the highlights.

Swappable Parsers for XMLmini

The support for XML parsing in ActiveSupport has been made more flexible by allowing you to swap in different parsers. By default, it uses the standard REXML implementation, but you can easily specify the faster LibXML or Nokogiri implementations for your own applications, provided you have the appropriate gems installed:


XmlMini.backend = 'LibXML'
XmlMini.backend = 'Nokogiri'

commit commit

rake gem Task Rewrite

The internals of the various rake gem tasks have been substantially revised, to make the system work better for a variety of cases. The gem system now knows the difference between development and runtime dependencies, has a more robust unpacking system, gives better information when querying for the status of gems, and is less prone to “chicken and egg” dependency issues when you’re bringing things up from scratch. There are also fixes for using gem commands under JRuby and for dependencies that try to bring in external copies of gems that are already vendored.

commit commit commit

Routing Fixes

A couple of small fixes to the routing engine. First, member routes with requirements now work (previously the requirements were ignored):


map.resources :orders, 
  :requirements => { :id => %r([^/;,?]+) }, 
  :member => { :accept => :get }

commit

Also, shallow routes now work properly with namespaces (commit) and you can now use the OPTIONS verb in route conditions (commit).

Client-side Caching Improvements

The expires_in, stale, and fresh_when methods now accept a :public option to make them work well with proxy caching.


expires_in 10.minutes, :public => true
fresh_when :last_modified => @user.updated_at.utc, 
  :public => true
fresh_when :etag => @user, :public => true

commit

Odds and Ends

The String#parameterize method now accepts an optional separator character.


"My big duck".parameterize =>      "my-big-duck"
"My big duck".parameterize('_') => "my_big_duck"

commit

The ActiveRecord::Base#invalid? method now works as the opposite of ActiveRecord::Base#valid?. (commit)

The ActiveSupport::Json.decode method now handles \u0000 style escape sequences. (commit)

You can now set content types such as multipart/mixed in Action Mailer. (commit)

Rails 2.3 will ship with a bundled version of Rack, but if you have Rack 1.0 installed as a gem it will use the gem version instead. (commit)

Update on Rails Guides and Documentation

We have been working on the Rails guides for some months now. With substantial contributions from a variety of authors, things are looking even better in the next version of the guides. That makes this the right time to take the overall documentation efforts to the next level.

Announcing the Documentation Team
We’re very happy to announce a formal documentation team – consisting of Xavier Noria, Mike Gunderloy and myself. However, eventually Mike and I will be just acting as advisors to the documentation team. So we’re definitely looking to empower some new faces here. If you’ve been working on improving the documentation and guides, keep up the good work and you’ll be on the team soon enough!

The documentation team will be to responsible for keeping the guides and API documentation up-to-date, working to improve the Rails documentation, and also helping more people contribute to the documentation efforts.

Documentation Mailing List and IRC
As part of the renewed documentation effort, we’re launching a mailing list. So go ahead and subscribe to rubyonrails-docs. The mailing list will be the main point of communication with the documentation team. If you have any suggestions or need any help, please post it to the mailing list. For quick questions, you can also find some of the team in the #docrails room on IRC most hours of the day.

How to Contribute
If you’re new to the Rails documentation process (or want to get involved for the first time!), you might want to have a look at the Contributing to the Rails Documentation section of the Contributing to Rails guide.

Rails Magazine #1 is Out

One of the measures of the health of a development platform is its ability to support a vibrant ecosystem of users, contributors, speakers, and authors. By this measure, Rails remains in excellent shape. The latest evidence: the release of the first issue of Rails Magazine – 36 pages of full-color glossy print.

The first issue includes 9 articles covering everything from delegation in Ruby to using Saasy for subscription-based applications to performance analysis and getting started with JRuby. The full content will be available on the web shortly, but if you’d like to support this effort (and help ensure that it doesn’t go away) you can order a paper copy for $8 in the US, UK, or Canada.

Rails 2.3 RC2: Final stop before release

The past month has seen a flurry of activity getting Rails 2.3 solid. We think we’ve ironed out all the major kinks now, but just to be sure, we’re running one last release candidate before it heads off to the presses. So please take some time to test out this release candidate. If we don’t get any reports of major blockers, we’re going to call this final within a week or two.

We’ve put together a complete guide for the Rails 2.3 release notes with all the information on what’s new, what’s changed, and what’s deprecated.

You can install the release candidate with:

gem install rails --source http://gems.rubyonrails.org

XSS and CSRF Vulnerabilities in the in_place_editing plugin

We have been advised of several vulnerabilities in the in_place_editing plugin which was created prior to the 2.0.0 release of Ruby on Rails.

  • The actions generated by in_place_edit_for perform no verification of the request method, allowing a hostile website to bypass built in CSRF protection.
  • The the input controls generated by in_place_editor_field perform no output sanitization, leaving the application vulnerable to XSS attacks.

Users of all versions of the plugin are advised to update to the latest version contained in our git repository at:

git://github.com/rails/in_place_editing.git

For users who are unable to use git, we have provided a zip file containing the patched code. The patch containing the fix is available also.

Users of all versions of Rails prior to 2.0 are advised to stop using the in_place_editing functionality, or manually apply those changes to their version of Rails. If these changes are backported, this post will be updated to include a patch for the relevant versions of rails.

Thanks to Pawel Stradomski of Code Sprinters for reporting this bug to us and working so patiently with us to get it resolved.

This Week in Edge Rails

February 14, 2009 – February 27, 2009

The sharp-eyed will notice that This Week covers two weeks this week. As Rails 2.3 approaches release, the core team is getting pickier about what goes into the source code, and is concentrating on fixing bugs. You can expect to see Rails 2.3 RC2 very soon, and that may be the last release candidate. So if you haven’t tested your own applications on Rails 2.3 yet, it’s time to do so. The edge code is generally stable right now, so it’s a great time to take a look.

Batch Processing

You can now process large numbers of records from an ActiveRecord model with less pressure on memory by using find_in_batches:


Customer.find_in_batches(:conditions => {:active => true}) do |customer_group|
  customer_group.each { |customer| customer.update_account_balance! }
end

You can pass most of the find options into find_in_batches. However, you cannot specify the order that records will be returned in (they will always be returned in ascending order of primary key, which must be an integer), or use the :limit option. Instead, use the :batch_size option, which defaults to 1000, to set the number of records that will be returned in each batch.

The new each method provides a wrapper around find_in_batches that returns individual records, with the find itself being done in batches (of 1000 by default):


Customer.each do |customer|
  customer.update_account_balance!
end

Note that you should only use this method when you have enough records to justify batch processing: for small numbers of records (less than 1000), you should just use the regular find methods with your own loop.

commit

A Note About Template Loading

After some extensive work by several authors (here’s the Lighthouse ticket), Rails 2.3 includes the ability to enable or disable cached templates for any particular environment. Cached templates give you a speed boost because they don’t check for a new template file when they’re rendered – but they also mean that you can’t replace a template “on the fly” without restarting the server.

In most cases, you’ll want template caching to be turned on in production, which you can do by making a setting in your production.rb file:


config.action_view.cache_template_loading = true

This line will be generated for you by default in a new Rails 2.3 application. But please note: if you’ve upgraded from an older version of Rails, you won’t have this setting in your production.rb and template caching will be off by default. Unless you really need the ability to update templates in production without restarting the server, you should be sure to add this setting when you upgrade.

2009 Ruby Hero Awards

There are many people in the Ruby community who contribute to our blossoming ecosystem. Some do this by producing educational content and others by contributing to open source libraries or helping out newcomers to the Ruby language. Every week I do my best to help promote the work of these people by talking about the most interesting bits on the Rails Envy Podcast. However, sometimes it just doesn’t seem like enough.

There are some developers who contribute to the community above and beyond the others. These people don’t always get the recognition they deserve, which is why last year I put together the Ruby Hero Awards. Hundreds of people submitted nominations and at RailsConf 2008 we gave away 6 awards to people in our community who deserved a round of applause.

Last year we gave awards to Ryan Bates, Yehuda Katz, Ilya Grigorik, Evan Weaver, Tom Copeland, and James Edward Gray II. This year we’re looking for 6 more people to give awards to and we need your nominations to figure out who you think deserves one. Three things to keep in mind here:

  • We’re looking for people who do not get their deserved recognition. For example, any of those Rails Activists and Rails Core members are out of the running.
  • When you submit a nomination you’ll have to enter 25 words as to why you think someone should be nominated.
  • The final 6 award winners will be determined by having the 6 winners from the previous year voting on them. The nominations you submit will certainly play a big factor in this decision, but won’t be the determining factor (this keeps things from turning into a popularity contest). So please don’t post to your blog telling all your friends to “Nominate You”, it ain’t gonna work.

The 6 winners will be announced on stage at RailsConf 2009, which is just around the corner. So if you know someone Ruby or Rails community who deserves some recognition, please take 2 minutes and submit a nomination for them.

Photo Credits: Ruby Hero Awards by Duncan Davidson, IMG_5428 by wyros

This Week in Edge Rails

February 7, 2009 – February 13, 2009

It’s been a fairly busy week on the edge, but there are not a lot of new features to point at. That’s good: at this point in the release cycle, the team is concentrating on nailing down things to be solid even in strange circumstances. This is also the point at which your help is critical: if a change affects one of your applications, and you don’t tell anyone about it, you can’t expect a fix. You don’t need to be running your applications full-time on RC1, but please, check out edge Rails, try it out, and report anything that seems to be broken. Bonus points if you include tests to show the expected behavior, and super bonus points if you submit a patch to go with it.

View Rendering Changes

A series of commits have addressed some issues with view rendering. The end result is to improve the performance of view rendering in development mode, and to bring back template recompiling in production mode (so you can change a view and have the changes show up without having to restart the whole server). Some of this work is ported from rails-dev-boost and if you want to come up to speed on what’s been done here the best thing to do is read the Lighthouse ticket

Partial Scoping for Translations

A change to the translation API makes things easier and less repetitive to write key translations within partials. If you call translate(".foo") from the people/index.html.erb template, you’ll actually be calling I18n.translate("people.index.foo") If you don’t prepend the key with a period, then the API doesn’t scope, just as before.

commit

Nested Attributes API Change

The API for NestedAttributes has been changed so as to work better with existing associations. If you’ve just used this for nested model forms, the changes will probably be transparent to you, but if you’ve been deeper into the internals you should have a look at the discussion in Lighthouse as well as the code in the commit.

commit

Less Brittle Tests for Scaffolded Controllers

The automatically-generated functional tests for controllers generated with script/generate scaffold now use to_param instead of id to identify records, which should make them more resilient to changes in fixtures over time.

commit

TimeWithZone changes

There were some internal changes to TimeWithZone that make its code more readable and efficient. One change surfaces to the API: TimeWithZone#to_formatted_s is an alias for TimeWithZone#to_s.

commit

A New Inflection

Breaking a long-standing policy, there was actually a change to the built-in list of pluralizations this week: Rails now handles database/databases correctly. Remember, a foolish consistency is the hobgoblin of little minds, and please don’t take this as an invitation to reopen the old ticket 10919. The policy remains that you can add inflections in your own application’s initializers if you need to do so.

The State of the Wiki

The new and revitalized Rails Wiki launched about two weeks ago, so it’s time for a progress report back to the Rails community. The short answer: things are going well. We’ve had nearly a hundred edits, dozens of topics put in place, and an active discussion on the wiki mailing list. Translators are already at work making the wiki content available in multiple languages. For topics ranging from a first Rails application walkthrough to handling timezones, the new wiki is already a spot to go for quality Rails content.

The wiki team has applied lessons learned from the old Rails wiki, which has gone from being a comfortable spot to find out a few things to a cluttered mess over the years. They started out by defining an overall structure and figuring out what warranted coverage in the wiki. Then they protected a few pages from edits and set up a login system to encourage accountability. The result, so far, is a very promising start at an information resource that can benefit all Rails developers.

But there’s plenty more to do. If you take a look at the new wiki home page you’ll find a bunch of topics in red with dashed underlines. Those are topics that we want, but that no one has written yet. If you have a few minutes to give back to the community, why not drop by? Whether it’s drafting a new topic from scratch, revising an existing topic to be more clear or correct, adding links to high-quality external resources, or translating the wiki into another language, there’s plenty left to do – and just about every Rails developer should be able to contribute.