There is exactly one overwhelming reason to use Fortitude:
It allows you to write vastly better-factored views.
With Fortitude, you can turn this:
<div class="container main outermost" id="main-container">
<div class="row primary">
<div class="col-sm-7">
<figure class="source">
<figcaption>example_code_1.rb</figcaption>
<pre class="ruby">
[ 1, 2, 3 ].map { |x| x * 2 } # => [ 2, 4, 6 ]
</pre>
</figure>
<%= render :partial => '/shared/buttons/icon_button', :locals => {
:target => conditional_refresh_url(:user => @user),
:icon_name => 'refresh',
:tooltip_html => "<p>Refresh this page</p>"
} %>
</div>
</div>
</div>
Into this:
simple_page {
ruby "example_code_1.rb", "[ 1, 2, 3 ].map { |x| x * 2 } # => [ 2, 4, 6 ]"
icon_button(:refresh, conditional_refresh_url(:user => @user)) {
p "Refresh this page"
}
}
…and that’s just the beginning. With Fortitude, you can refactor your views into the methods that are right for your application. This means:
Fortitude expresses your views using a Ruby DSL that models HTML; this allows you to bring all the power of Ruby to bear on your views. The difference this makes in the long run is enormous.
However, beyond the code-factoring abilities of Fortitude, it also offers a number of other very powerful features that you’ll love in a templating engine:
<div> inside a <p> — and, if you want, can enforce them for you. No more invalid markup!
id Uniqueness Enforcement: Fortitude can let you know if you re-use the same DOM ID on a page accidentally. No more difficult debugging sessions because your JavaScript is attaching to the wrong element!
It’s easiest to explain by example. Follow the link below, and you’ll see seven examples of using Fortitude to refactor common view problems into clear, concise, powerful code.