What's New in Sinatra 1.2?
Sinatra now supports the Slim Template Engine:
Like Builder and Nokogiri templates, Markaby can now be used directly inline:
Whenever you render a template, like
some_page.haml, Sinatra will use a
corresponding layout, like
layout.haml for you. With the
:layout option it
has always been possible to use a different layout, but it still had to be
written in the same template language, Haml in our example. In 1.1 we introduced
rdoc templates. It is not possible to use those for
layouts. We therefore added the
:layout_engine option, which easily allows you
to combine one two different template engines:
This feature should also be handy when migrating from one template language to another, as it allows you to combine Erb with Haml, for instance.
We introduced pattern matching filters in 1.1. Now they also support conditions:
Those can also be combined with patterns, of course:
Usually Sinatra does not provide any view helper methods. Those are provided by extensions and would not suit Sinatra’s approach of a small but robust core. However, constructing URLs is a use case most people run into sooner or later. It is a bit complicated to construct URLs right. Consider this example:
Feel free to run it. Works, doesn’t it? So, what is wrong with it?
Imagine your app is “mounted” by another Rack application, for instance in a
config.ru like this:
Now the link to
/bar would end up in a request send to
than to Sinatra. Injecting
request.script_name would fix this, but be
honest, how often do you do that?
Now, imagine these links are presented out of context, in an RSS feed or
embedded on another host. In that case you might want to construct absolute
URLs. This is even more cumbersome, as you most certainly either forget to
handle reverse proxies, alternative ports/protocols or you end up with lots of
URL related code all over the place, while what you should do is use the
Since you are likely going to use this with redirects, we also aliased the
Named Captures on 1.9
Ruby 1.9 introduced named captures
for regular expressions. Sinatra accepts regular expressions for matching paths.
Now named captures will automatically end up populating
Templates with different scopes
All rendering methods now accept a
Note that all Sinatra helper methods and instance variables will not be available.
In 1.1 we made sure all redirects were absolute URIs, to conform with RFC 2616
(HTTP 1.1). This will result in issues for you if you have a broken Reverse
Proxy configuration. If so, you should really fix your configuration. If you are
unable to do so, a simple
disable :absolute_redirects will now give you back
the 1.0 behavior. As shown above, you can now use the
to helper with redirect.
If all your redirects are application local, you can now
enable :prefixed_redirects and skip the
We did not enable this per default to not break compatibility and to allow you redirects to other Rack endpoints.
Overriding template lookup
One popular feature request is supporting multiple view folders. But everyone wants different semantics. So, instead of choosing one way to go, we gave you means to implement your own lookup logic:
Sinatra will call
find_template to discover the template file. In the above
example, we don’t care about what template engine to use or what name the
template has. It will use
views/index.html for every
template. Let’s have a look at the standard implementation:
As you can see, it will look in the views folder for a file named like the template with any of the file extensions registered for the template engine.
If all you want to change is the folder, you probably should just call
More examples can be found in the readme.
send_filenow takes a
- improved error handling