Roughly a month has went by since our last release and there have been several developments since then. Today, we are release our first minor point release in a while because we have introduced a breaking change to the way Padrino loads our rendering module.

This 0.10.0 release brings a couple new features such as enhanced route filter support, significantly faster routing engine, full compatibility with Rubinius and JRuby, bug fixes and several other improvements. The next releases coming in the pipeline are 0.10.1 (for Sinatra 1.3), 0.10.2 (for AS 3.1) and then a release candidate for our 1.0 release barring any major complications. Details for this release are below.

Rendering Module Changes

In this release, we have introduced a breaking change to the way Padrino loads the Padrino::Rendering module. Working with botanicus recently on an issue, we uncovered a problem with the auto-loading of our enhanced rendering module.

The issue is that any extension to Sinatra/Padrino that wishes to extend rendering was unable to load before our module. This produced situations where Padrino rendering is difficult to enhance with outside extensions. We have decided to remove the autoloading of Padrino::Rendering. For freshly generated applications, no action needs to be taken because Rendering will be included in the generated application.

For an existing application, all you need to do is add an explicit include to Padrino::Rendering:

on every application within a project. For those that are curious, the Padrino::Rendering module is the functionality that enhances “render” to auto-locate templates and adds support for I18n amongst a variety of other conveniences that makes template rendering much more powerful and convenient. If you are using render "index" in your code then you are using this module. Commit here.

Rubinius and JRuby Compatibility

This release also marks full support for Rubinius and JRuby, two of the upcoming stable ruby implementations gaining attention. As of this tweet, we are now 100% compatible with Rubinius and have tested full support for JRuby. Uchio Kondo, the official Japanese documentation maintainer for Padrino has also created an excellent guide for Running Padrino on JRuby which gets you started. Commits here, here, and here.

Routing Speed Improvements

Josh has enabled serious performance gains in http_router which has once again allowed Padrino to parallel Sinatra in performance even in an more advanced demo application. In all our benchmarks, Sinatra and Padrino are generally neck-in-neck:

Commits here to upgrade http_router and take advantage of the optimizations. Thanks again to joshbuddy (Joshua Hull) of our core team for hacking on these upgrades!

Route Filters

An oft-requested feature is for enhanced route filters. While Sinatra does have basic support for filters, a heavy user will often find that it leaves things to be desired. Namely when dealing with namespaces and routes. Whereas before, a filter looks like this:

# app/controllers/example_controller.rb
DemoApp.controller :example do
before "/example/*" do
# Code here to be executed
end
get :index do
# ...
end
end

Now you can have a lot more options related to filters and they work much more intuitively thanks to Joshua (joshbuddy) and you can do:

# app/controllers/example_controller.rb
DemoApp.controller :example do
# Based on a symbol
before :index do
# Code here to be executed
end
# Based on a symbol, regexp and string all in one
before :index, /main/, '/example' do
# Code here to be executed
end
# Also filter by excluding an action
before :except => :index do
# Code here to be executed
end
get :index do
# ...
end
end

This gives developers a lot more flexibility when running filters and enables much more selective execution in a convenient way. Great to have this feature available as part of our routing enhancements. Commits here and here.

Route Ordered Priority

This release has also added support for respecting route order in controllers and also allows the developer to specify certain routes as less or more “important” then others in the route recognition order. Consider two controllers, the first with a “catch-all” route that matches any URL and the second below in another controller that is very specific. This wouldn't work by default because the second endpoint would be eclipsed by the catch-all route and as such would not be accessible. To solve this, you can do the following:

# app/controllers/pages.rb
MyApp.controller :pages do
# NOTE that this route is now marked as low priority
get :show, :map => :map => '/*page', :priority => :low do
"Catchall route"
end
end
# app/controllers/projects.rb
MyApp.controller :projects do
get :index do
"Important Index"
end
end

When setting a routes priority to :low, this route is then recognized in order lower then all “high” and “normal” priority routes. You are encouraged in cases where there is ambiguity, to mark key routes as :priority => :high or catch-all routes as :priority => :low in order to guarantee expected behavior.

Contribute

Please report any issues you encounter with this release! We are working very actively on Padrino and want to make the framework as stable and reliable as possible. That concludes the changelog for this release. As always if you want to keep up with Padrino updates, be sure to follow us on twitter: @padrinorb, join us on IRC at “#padrino” on freenode, open an issue, or discuss on gitter.