Enable or Disable
layout.<extension> via regex.
How many times did you wished you could do something like this:
class App < Sinatra::Base register Sinatra::FuzzyLayout enable_layout_for "home", :admin disable_layout_for /.+_reports/ get '/' do haml :index # layout.haml is used end get '/admin' do haml :admin # layout.haml is used end get '/home' do haml :home # layout.haml is used end get '/system_reports' do haml :system_reports # layout.haml is not used. end end
gem install 'sinatra-fuzzy_layout'
Or, if your use bundler like the pros, add this line to your application's Gemfile:
And then execute:
Once the gem is installed, add this in your app file:
require the gem, you can define the
An additional step in case of Modular style apps is :
require "sinatra/fuzzy_layout" # just like in classic style class App < Sinatra::Base register Sinatra::FuzzyLayout enable_layout_for :a_template end
(Note: if you use a different templating engine like
replace all instances of
haml with that engine here on)
When the app encounters a
haml :view in a route,
it tries to render that view by reading the
view.haml file and checking
to see if a
layout option is defined. This usually is set at a global
level in the app
set :haml, :layout => false or set on a per-route
haml :view, :layout => false. If the layout is required, then the
layout.haml is also parsed and the
view.haml part is added to the
This extension lets you define the layout options at a global level.
It modifies the
render method in
Sinatra::Templates so that the templates
are checked against the regexes defined and the layout option is set
(or unset) based on the result.
A template is first validated against the
enable_layouts_for options. If the
enable_layouts_for directive is not defined in the app however, the check
only happens against
disable_layouts_for. If the first check returns true,
i.e., if the layout is enabled for that template, the second check never
happens. This means that if you define a template in both the
disable_layouts_for directives, the layout gets enabled
since the first check returns true.
Typically, only one template is used in each route (duh!). This means that the regex checks happen only one in the best case and twice in the worst case and so should not affect performance by a large margin. However, if you are writing at webscale, you might want to skip this.
Even if you use this plugin, it won't interfere with the normal Sinatra layout directives (global and per-route) and so, you can mix-and-match if you're into it. If you're still uncertain whether or not to use it, but want to, I'd say go ahead.
- Fork it
- Create your feature branch (
git checkout -b my-new-feature)
- Commit your changes (
git commit -am 'Add some feature')
- Push to the branch (
git push origin my-new-feature)
- Create new Pull Request