fortitude 0.9.5-java → 0.9.6-java

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 6c0cdd4f8163e6329ea53df6eb0f3cdd0f7b462a
-  data.tar.gz: e562cb7ca19a1fdb2ae5aad46045e44da00f9e7e
+  metadata.gz: 53c8bb7a7a3cf5effe1af6eea8b82d257151606d
+  data.tar.gz: 62b331d7eab7220f441ca68e622626ec88e45d15
 SHA512:
-  metadata.gz: cab578b4fa509f130887152e3ee5f82784f436b02b9b2c12bd8d853e386954d5fba911ff646d1b95bb8849919f9f75dfc6606d9e5d9c7992008e284e65842141
-  data.tar.gz: 5cdc304ee2ffec321ee2b6c316007208b043accc297b0e6299f5748889e919e3b8a9d29358c9745ef5b0d685c4c5181b1ee2a45d6f24e872955cfc11669ed98e
+  metadata.gz: 79389c098683a325bb8204d973f7f568a97e244a0da44d56fbb43682324f8cb0324948b171bd1e385c8c98bbf9ccf329e300bf125e26ec4bc41883d306517e9d
+  data.tar.gz: b63570ebefea3f89686b43d25e39fa4a0d7b1efb6bb0c8187f6ac3d231a740d13d6f5681eca222661e266b1670450d20635cf3514b6a5b5bf381d94d98acc68d

data/CHANGES.md

@@ -1,5 +1,16 @@
 # Fortitude Releases
 
+## 0.9.6, 21 October 2016
+
+* Generator support: generation of controllers, mailers, and scaffolding will now produce nice Fortitude views
+  instead of ERb views. (You can add `-e erb` to your `rails generate` command line to switch back to ERb if
+  desired.) Thanks to [Gaelan](https://github.com/Gaelan) for the suggestion!
+* Fixed an issue where if you tried to invoke methods on the object yielded to a `form_for` call or similar
+  by using `send` instead of calling it directly (_e.g._, `form_for(...) do |f|`, then `f.send(:text_field, ...)`
+  instead of `f.text_field ...`), the method invocation would appear to be ignored.
+* Fixed an issue where Rails `_url`/`_path` helpers didn't correctly pick up parameters set from the incoming
+  request. (Thanks to [Adam Becker](https://github.com/ajb) for the bug report!)
+
 ## 0.9.5, 12 October 2016
 
 * Rails 5 compatibility: Fortitude now is fully compatible with Rails 5.0.0.1.

data/CONTRIBUTORS.md

@@ -54,6 +54,8 @@ Fortitude is written by [Andrew Geweke](https://github.com/ageweke), with contri
     (specifically, `<`, `>`, and `'`).
   * Reporting an issue where you couldn't use `inline_html` in a way that allowed you to pass a
     `Fortitude::RenderingContext`, thus preventing you from using it with code that required access to helpers.
+  * Reporting an issue where Rails' `_url`/`_path` helpers wouldn't pick up parameters set from the inbound request
+    correctly.
 * [Karl He](https://github.com/karlhe) for:
   * Reporting an issue (and supplying an example patch) where Fortitude wasn't respecting Rails' additional view
     paths correctly &mdash; only `app/views`.
@@ -67,3 +69,5 @@ Fortitude is written by [Andrew Geweke](https://github.com/ageweke), with contri
   * Fixes for compatibility with Rails 5.
 * [Matt Walters](https://github.com/mattwalters) for:
   * A patch to make built-in Rails helpers work even when `automatic_helper_access` was set to `false`.
+* [Gaelan](https://github.com/Gaelan) for:
+  * Suggesting generator support for Fortitude.

data/fortitude.gemspec

@@ -52,7 +52,7 @@ Gem::Specification.new do |s|
   s.add_development_dependency "rspec", "~> 2.99"
   s.add_development_dependency "rake-compiler"
   s.add_development_dependency "tilt", "~> 2.0"
-  s.add_development_dependency "oop_rails_server", ">= 0.0.22"
+  s.add_development_dependency "oop_rails_server", ">= 0.0.24"
 
   # This is because i18n >= 0.7 is incompatible with Ruby 1.8.x.
   if RUBY_VERSION =~ /^1\.8\./

data/lib/fortitude/rails/helpers.rb

@@ -12,10 +12,24 @@ module Fortitude
         end
 
         def apply_refined_helpers_to!(o)
-          o.send(:include, ::Rails.application.routes.url_helpers)
           @helpers.each do |name, options|
             o.helper(name, options)
           end
+
+          url_helpers_module = ::Rails.application.routes.url_helpers
+
+          test_base_class = Class.new
+          test_base_instance = test_base_class.new
+
+          test_class = Class.new
+          test_class.send(:include, url_helpers_module)
+          test_instance = test_class.new
+
+          metaclass = o.instance_eval("class << self; self; end")
+
+          metaclass.send(:define_method, :_fortitude_allow_helper_even_without_automatic_helper_access?) do |method_name|
+            test_instance.respond_to?(method_name) && (! test_base_instance.respond_to?(method_name))
+          end
         end
 
         ALL_BUILTIN_HELPER_MODULES = {
@@ -45,6 +59,11 @@ module Fortitude
           }
         }
 
+        # We could use the mechanism used above for the url_helpers_module, but this makes access to these helpers
+        # much faster -- they end up with real methods defined for them, instead of using method_missing magic
+        # every time. We don't necessarily want to do that for the url_helpers_module, because there can be tons and
+        # tons of methods in there...and because we initialize early-enough on that methods aren't defined there yet,
+        # anyway.
         def declare_all_builtin_rails_helpers!
           ALL_BUILTIN_HELPER_MODULES.each do |base_module, constant_names|
             constant_names.each do |constant_name|

data/lib/fortitude/rails/railtie.rb

@@ -25,6 +25,8 @@ end
 module Fortitude
   module Rails
     class Railtie < ::Rails::Railtie
+      config.app_generators.template_engine :fortitude
+
       class << self
         def _fortitude_view_roots
           @_fortitude_view_roots_mutex.synchronize do

data/lib/fortitude/rails/yielded_object_outputter.rb

@@ -29,6 +29,9 @@ module Fortitude
       EMPTY_RETURN_VALUE = ''.freeze
 
       def method_missing(method_name, *args, &block)
+        method_name = method_name.to_sym
+        method_name = args.shift if method_name == :send
+
         if @method_names_hash[method_name.to_sym]
           block = ::Fortitude::Rails::YieldedObjectOutputter.wrap_block_as_needed(@output_target, method_name, block, @method_names_hash.keys)
           return_value = @yielded_object.send(method_name, *args, &block)

data/lib/fortitude/version.rb

@@ -1,3 +1,3 @@
 module Fortitude
-  VERSION = "0.9.5"
+  VERSION = "0.9.6"
 end

data/lib/fortitude/widget/integration.rb

@@ -56,13 +56,27 @@ module Fortitude
         out
       end
 
+      def _fortitude_use_helper?(method_name)
+        unless @_fortitude_rendering_context && @_fortitude_rendering_context.helpers_object && @_fortitude_rendering_context.helpers_object.respond_to?(method_name, true)
+          return false
+        end
+
+        return self.class.automatic_helper_access ||
+          (self.class.respond_to?(:_fortitude_allow_helper_even_without_automatic_helper_access?) &&
+           self.class._fortitude_allow_helper_even_without_automatic_helper_access?(method_name))
+      end
+
+      def _fortitude_allow_helper_even_without_automatic_helper_access?(method_name)
+        false
+      end
+
       def _fortitude_target_method_and_args_for_method_missing(missing_method_name, *missing_method_args, &missing_method_block)
         if self.class.extra_assigns == :use && missing_method_args.length == 0 && (! missing_method_block)
           ivar_name = self.class.instance_variable_name_for_need(missing_method_name)
           return [ self, :instance_variable_get, ivar_name ] if instance_variable_defined?(ivar_name)
         end
 
-        if self.class.automatic_helper_access && @_fortitude_rendering_context && @_fortitude_rendering_context.helpers_object && @_fortitude_rendering_context.helpers_object.respond_to?(missing_method_name, true)
+        if _fortitude_use_helper?(missing_method_name)
           return [ @_fortitude_rendering_context.helpers_object, missing_method_name, *missing_method_args ]
         end
 

data/lib/rails/generators/fortitude/base_view/base_view_generator.rb

@@ -0,0 +1,13 @@
+require 'rails/generators/erb/controller/controller_generator'
+
+module Fortitude
+  module Generators
+    class BaseViewGenerator < ::Rails::Generators::Base
+      source_root File.join(File.dirname(__FILE__), 'templates')
+
+      def create_view_base
+        template "views_base.rb", 'app/views/base.rb', :skip => true
+      end
+    end
+  end
+end

data/lib/rails/generators/fortitude/base_view/templates/views_base.rb

@@ -0,0 +1,230 @@
+class Views::Base < Fortitude::Widget
+  # You can configure the behavior of Fortitude in this file.
+  #
+  # Don't be afraid -- by default you can simply ignore this file, and probably everything will
+  # work exactly as you'd expect. Come back to it if you want to tweak Fortitude's behavior or
+  # read about some of its more interesting features.
+  #
+  #
+  # Fortitude configuration options apply to the class they're invoked on, and all subclasses.
+  # By convention, app/views/base.rb holds Views::Base, which is used as the superclass of all
+  # Fortitude widgets in a Rails application -- thus, configuration set here will apply to all
+  # Fortitude widgets. However, you can create any subclasses of this class you want, and set
+  # different configuration there, which will apply to all subclasses of those widgets.
+  # (For example, you could create app/views/admin/base.rb containing
+  # Views::Admin::Base < Views::Base, and set configuration there that would only apply to any
+  # widget inheriting from Views::Admin::Base). The only exception is `doctype`, which cannot
+  # be set on the descendant of any class that's set it itself.
+  #
+  # Below are all the current Fortitude configuration options, as of the creation of this file.
+
+
+  # This controls the set of tags available to you (and the nesting and attributes they allow,
+  # if you enable enforce_element_nesting_rules or enforce_attribute_rules). It also controls
+  # what the `doctype!` method outputs, and related behavior (such as how self-closing elements
+  # like <br> render).
+  #
+  # You can choose from :html5, :html4_transitional, :html4_strict, :html4_frameset,
+  # :xhtml11, :xhtml10_transitional, :xhtml10_strict, and :xhtml10_frameset.
+  doctype :html5
+
+
+
+  # format_output: default true in development mode, false otherwise
+  #
+  # format_output causes the output of "pretty-printed" HTML, beautifully nested and easy for
+  # humans to read. If set to false, HTML is produced with as little whitespace as possible
+  # while preserving meaning -- better for production, where minimizing size of generated HTML
+  # is more important.
+
+  # format_output (!! Rails.env.development?)
+
+
+  # start_and_end_comments: default true in development mode, false otherwise
+  #
+  # start_and_end_comments causes comments to be written into the HTML at the start and end
+  # of every widget rendered, showing the class name of the widget, its nesting depth, and
+  # all the arguments passed to that widget. This makes it vastly easier to look at the HTML
+  # generated for an entire page and know exactly which view file to go change in order to
+  # change that HTML.
+
+  # start_and_end_comments (!! Rails.env.development?)
+
+
+  # debug: default true in development mode, false otherwise
+  #
+  # debug alerts you when a rare, but extremely-difficult-to-debug, situation arises.
+  # Fortitude prioritizes parameters declared using 'need' above its built-in HTML tags.
+  # As an example, if you pass a parameter called `time` to your view by saying
+  # `needs :time`, then the method `time` in your widget will return the value of that
+  # attribute, rather than (as it otherwise would) rendering the HTML5 `<time>` tag.
+  # This is fine (and you can always use `tag_time` to get the HTML5 tag).
+  #
+  # But say you forget, imagine it's the tag, and write the following:
+  # time { p "this is the time" } (or something similar). Because time is now a method
+  # that simply returns the value of the `time` parameter, this code will do absolutely
+  # nothing -- it's throwing away the block passed to it, returning the `time` parameter,
+  # and outputting nothing. Needless to say, this can be extremely frustrating to debug.
+  #
+  # If `debug` is true, then, the code above will raise an exception
+  # (Fortitude::Errors::BlockPassedToNeedMethod) instead of ignoring the block, and it'll be
+  # dramatically easier to debug.
+
+  # debug (!! Rails.env.development?)
+
+
+  # enforce_element_nesting_rules: default false
+  #
+  # If set to true, Fortitude will require you to respect the HTML element-nesting rules
+  # (for example, you can't put a <div> inside a <p>), and will raise an exception
+  # (Fortitude::Errors::InvalidElementNesting) if you do something the HTML spec disallows.
+  # This can be extremely useful in helping you to write clean HTML.
+  #
+  # There is a small speed penalty for turning this on, so it's recommended you only enable
+  # it in development mode.
+
+  # enforce_element_nesting_rules false
+
+
+  # enforce_attribute_rules: default false
+  #
+  # If set to true, Fortitude will prevent you from using any attribute that isn't defined
+  # in the HTML spec, and will raise a Fortitude::Errors::InvalidElementAttributes error
+  # if you do otherwise. (Note that any attribute starting with 'data-' or 'aria-' is allowed,
+  # since that's in the spec.) This can be extremely useful in helping you to write clean
+  # HTML.
+  #
+  # There is a small speed penalty for turning this on, so it's recommended you only enable
+  # it in development mode.
+
+  # enforce_attribute_rules false
+
+
+  # enforce_id_uniqueness: default false
+  #
+  # If set to true, Fortitude will prevent you from giving multiple elements the same 'id'
+  # on a page, and will raise a Fortitude::Errors::DuplicateId if you do. This can be
+  # extremely useful in helping you to write clean HTML.
+  #
+  # There is a small speed penalty for turning this on, so it's recommended you only enable
+  # it in development mode.
+
+  # enforce_id_uniqueness false
+
+
+  # close_void_tags: default false
+  #
+  # In HTML5, "self-closing" tags like `<br>` can be written as `<br>` or `<br/>`; either is
+  # legal. (In HTML4, `<br/>` is not legal, and neither is `<br></br>`. In XML, `<br/>` or
+  # `<br></br>` is mandatory.) By default, Fortitude will output `<br>`. However, if you set
+  # `close_void_tags` to true, then Fortitude will output `<br/>`, instead. Attempting to
+  # change this to true in a HTML4 doctype or false for an XHTML doctype will result in an
+  # error.
+
+  # close_void_tags false
+
+
+  # extra_assigns: default :ignore
+  #
+  # This controls what happens if you pass parameters to a widget that it hasn't declared a
+  # `need` for. If set to `:ignore`, it will simply ignore them; they will not be available to
+  # the widget to use. If set to `:use`, it will make them available for use in the widget --
+  # this is not recommended, however; it's better for the widget to declare all parameters
+  # it possibly could use, giving them defaults, instead of making undeclared parameters
+  # magically accessible. If set to `:error`, Fortitude will raise a
+  # Fortitude::Errors::ExtraAssigns in this case. (However, assigning "extra" variables in
+  # a Rails controller -- e.g., assigning `@foo`, then rendering a view that doesn't
+  # `need :foo` -- will never cause this error.)
+  #
+  # It can be useful to set this to :error if writing brand-new views (rather than translating
+  # old ERb views to Fortitude), since it will enforce cleaner code.
+  #
+  # There is a small speed penalty for setting this to `:use`.
+
+  # extra_assigns :ignore
+
+
+  # automatic_helper_access: default true
+  #
+  # If set to true, Fortitude's access to helpers works identically to ERb's -- i.e., you can
+  # use any helper in a Fortitude widget that would be accessible to an equivalent ERb view.
+  # If set to false, however, only helpers built-in to Rails and those you manually declare
+  # using `helper :foo` are accessible. This can be useful if starting to use Fortitude in
+  # a large, messy ERb/HAML/whatever codebase with many helpers, where you don't want new
+  # Fortitude code to start using a large variety of perhaps less-than-ideal helpers.
+
+  # automatic_helper_access true
+
+
+  # implicit_shared_variable_access: default false
+  #
+  # Rails ERb views use a giant bag of global state: not only can views access any `@foo`
+  # controller variable, but partials can, too, even if not passed to them -- and, even
+  # worse, they can _write_ to them. Fortitude disallows all of this by default; the only
+  # variables accessible to a Fortitude widget are those passed in directly and that it
+  # `:needs`. This results in vastly cleaner views. (If you really want to access such
+  # variables, even in Fortitude, they are available in a `shared_variables` `Hash`-like
+  # object that's accessible by widgets.)
+  #
+  # However, if you're translating legacy code from ERB/HAML/whatever to Fortitude, you may
+  # find that lots of code depends on this sort of action-at-a-distance, to the point where
+  # translating it is no longer feasible. If so, you can set `implicit_shared_variable_access`
+  # to `true`, and then you can read (and write!) any of these shared variables by simply
+  # using the normal syntax (`@foo`).
+  #
+  # There is a small speed penalty for enabling this.
+
+  # implicit_shared_variable_access false
+
+
+  # use_instance_variables_for_assigns: default false
+  #
+  # By default, parameters passed to a Fortitude widget are accessible using Ruby reader/
+  # method syntax (`foo`), and _not_ using Ruby instance-variable syntax (`@foo`). This
+  # has many advantages, not the least of which is that typos result in a clean exception
+  # instead of a "parameter" that happens to always be `nil`.
+  #
+  # However, if you're translating legacy code from ERB/HAML/whatever to Fortitude, you may
+  # find that lots of code depends on accessing parameters as instance variables. Setting
+  # this to `true` will expose parameters in both styles (`foo` and `@foo`). (Read, however,
+  # about `implicit_shared_variable_access`, above, too -- only by setting that also will
+  # Fortitude behave exactly like ERb in all such situations.)
+
+  # use_instance_variables_for_assigns false
+
+
+  # translation_base: default nil
+  #
+  # Rails' translation helper (usually called as `#t`, as in `t(:welcome_message)`) allows
+  # you to easily localize views. When called with a string starting with a dot,
+  # Rails normally prepends the view path to the key before looking it up -- for example,
+  # in app/views/foo/bar.html.rb, calling `t('.baz')` is equivalent to calling
+  # `t('foo.bar.baz'). However, in Fortitude, you can change this by setting `translation_base`
+  # to a string; this will prepend that string, before passing it onwards. (The
+  # `translation_base` string itself can even start with a dot, in which case it will be
+  # passed onwards to Rails' mechanism, which will then still add the view prefix before
+  # looking up the translation.)
+  #
+  # While generally not needed, this can be used to help clean up legacy applications with
+  # messy translations. For example, setting this to `fortitude.` will allow you to segregate
+  # all Fortitude translations under a top-level `fortitude` key, while setting it to
+  # `.fortitude.` will allow you to segregate each view's Fortitude translations under a
+  # Fortitude key underneath that view path.
+  #
+  # If this is used by any widget in the entire system, there is a small speed penalty applied
+  # to all calls of `#t` -- so only use this if you really need it.
+
+  # translation_base nil
+
+
+  # use_localized_content_methods: default false
+  #
+  # If set to true, then, if (for example) the locale is set to `fr`, Fortitude will look
+  # for a method in the widget called `#localized_content_fr`; if it exists, it will call
+  # that method _instead_ of `#content`. This provides support for views that may differ
+  # dramatically from one locale to the next.
+  #
+  # There is a very small speed penalty for any widget using this feature.
+
+  # use_localized_content_methods false
+end

data/lib/rails/generators/fortitude/controller/controller_generator.rb

@@ -0,0 +1,18 @@
+require 'rails/generators/erb/controller/controller_generator'
+
+module Fortitude
+  module Generators
+    class ControllerGenerator < Erb::Generators::ControllerGenerator
+      source_root File.join(File.dirname(__FILE__), 'templates')
+
+      def create_view_base
+        generate "fortitude:base_view"
+      end
+
+      protected
+      def handler
+        :rb
+      end
+    end
+  end
+end

data/lib/rails/generators/fortitude/controller/templates/view.html.rb

@@ -0,0 +1,6 @@
+class Views::<%= class_name.camelize %>::<%= @action.camelize %> < Views::Base
+  def content
+    h1 "<%= class_name %>#<%= @action %>"
+    p "Find me in <%= @path %>"
+  end
+end

data/lib/rails/generators/fortitude/controller/templates/views_base.rb

@@ -0,0 +1,230 @@
+class Views::Base < Fortitude::Widget
+  # You can configure the behavior of Fortitude in this file.
+  #
+  # Don't be afraid -- by default you can simply ignore this file, and probably everything will
+  # work exactly as you'd expect. Come back to it if you want to tweak Fortitude's behavior or
+  # read about some of its more interesting features.
+  #
+  #
+  # Fortitude configuration options apply to the class they're invoked on, and all subclasses.
+  # By convention, app/views/base.rb holds Views::Base, which is used as the superclass of all
+  # Fortitude widgets in a Rails application -- thus, configuration set here will apply to all
+  # Fortitude widgets. However, you can create any subclasses of this class you want, and set
+  # different configuration there, which will apply to all subclasses of those widgets.
+  # (For example, you could create app/views/admin/base.rb containing
+  # Views::Admin::Base < Views::Base, and set configuration there that would only apply to any
+  # widget inheriting from Views::Admin::Base). The only exception is `doctype`, which cannot
+  # be set on the descendant of any class that's set it itself.
+  #
+  # Below are all the current Fortitude configuration options, as of the creation of this file.
+
+
+  # This controls the set of tags available to you (and the nesting and attributes they allow,
+  # if you enable enforce_element_nesting_rules or enforce_attribute_rules). It also controls
+  # what the `doctype!` method outputs, and related behavior (such as how self-closing elements
+  # like <br> render).
+  #
+  # You can choose from :html5, :html4_transitional, :html4_strict, :html4_frameset,
+  # :xhtml11, :xhtml10_transitional, :xhtml10_strict, and :xhtml10_frameset.
+  doctype :html5
+
+
+
+  # format_output: default true in development mode, false otherwise
+  #
+  # format_output causes the output of "pretty-printed" HTML, beautifully nested and easy for
+  # humans to read. If set to false, HTML is produced with as little whitespace as possible
+  # while preserving meaning -- better for production, where minimizing size of generated HTML
+  # is more important.
+
+  # format_output (!! Rails.env.development?)
+
+
+  # start_and_end_comments: default true in development mode, false otherwise
+  #
+  # start_and_end_comments causes comments to be written into the HTML at the start and end
+  # of every widget rendered, showing the class name of the widget, its nesting depth, and
+  # all the arguments passed to that widget. This makes it vastly easier to look at the HTML
+  # generated for an entire page and know exactly which view file to go change in order to
+  # change that HTML.
+
+  # start_and_end_comments (!! Rails.env.development?)
+
+
+  # debug: default true in development mode, false otherwise
+  #
+  # debug alerts you when a rare, but extremely-difficult-to-debug, situation arises.
+  # Fortitude prioritizes parameters declared using 'need' above its built-in HTML tags.
+  # As an example, if you pass a parameter called `time` to your view by saying
+  # `needs :time`, then the method `time` in your widget will return the value of that
+  # attribute, rather than (as it otherwise would) rendering the HTML5 `<time>` tag.
+  # This is fine (and you can always use `tag_time` to get the HTML5 tag).
+  #
+  # But say you forget, imagine it's the tag, and write the following:
+  # time { p "this is the time" } (or something similar). Because time is now a method
+  # that simply returns the value of the `time` parameter, this code will do absolutely
+  # nothing -- it's throwing away the block passed to it, returning the `time` parameter,
+  # and outputting nothing. Needless to say, this can be extremely frustrating to debug.
+  #
+  # If `debug` is true, then, the code above will raise an exception
+  # (Fortitude::Errors::BlockPassedToNeedMethod) instead of ignoring the block, and it'll be
+  # dramatically easier to debug.
+
+  # debug (!! Rails.env.development?)
+
+
+  # enforce_element_nesting_rules: default false
+  #
+  # If set to true, Fortitude will require you to respect the HTML element-nesting rules
+  # (for example, you can't put a <div> inside a <p>), and will raise an exception
+  # (Fortitude::Errors::InvalidElementNesting) if you do something the HTML spec disallows.
+  # This can be extremely useful in helping you to write clean HTML.
+  #
+  # There is a small speed penalty for turning this on, so it's recommended you only enable
+  # it in development mode.
+
+  # enforce_element_nesting_rules false
+
+
+  # enforce_attribute_rules: default false
+  #
+  # If set to true, Fortitude will prevent you from using any attribute that isn't defined
+  # in the HTML spec, and will raise a Fortitude::Errors::InvalidElementAttributes error
+  # if you do otherwise. (Note that any attribute starting with 'data-' or 'aria-' is allowed,
+  # since that's in the spec.) This can be extremely useful in helping you to write clean
+  # HTML.
+  #
+  # There is a small speed penalty for turning this on, so it's recommended you only enable
+  # it in development mode.
+
+  # enforce_attribute_rules false
+
+
+  # enforce_id_uniqueness: default false
+  #
+  # If set to true, Fortitude will prevent you from giving multiple elements the same 'id'
+  # on a page, and will raise a Fortitude::Errors::DuplicateId if you do. This can be
+  # extremely useful in helping you to write clean HTML.
+  #
+  # There is a small speed penalty for turning this on, so it's recommended you only enable
+  # it in development mode.
+
+  # enforce_id_uniqueness false
+
+
+  # close_void_tags: default false
+  #
+  # In HTML5, "self-closing" tags like `<br>` can be written as `<br>` or `<br/>`; either is
+  # legal. (In HTML4, `<br/>` is not legal, and neither is `<br></br>`. In XML, `<br/>` or
+  # `<br></br>` is mandatory.) By default, Fortitude will output `<br>`. However, if you set
+  # `close_void_tags` to true, then Fortitude will output `<br/>`, instead. Attempting to
+  # change this to true in a HTML4 doctype or false for an XHTML doctype will result in an
+  # error.
+
+  # close_void_tags false
+
+
+  # extra_assigns: default :ignore
+  #
+  # This controls what happens if you pass parameters to a widget that it hasn't declared a
+  # `need` for. If set to `:ignore`, it will simply ignore them; they will not be available to
+  # the widget to use. If set to `:use`, it will make them available for use in the widget --
+  # this is not recommended, however; it's better for the widget to declare all parameters
+  # it possibly could use, giving them defaults, instead of making undeclared parameters
+  # magically accessible. If set to `:error`, Fortitude will raise a
+  # Fortitude::Errors::ExtraAssigns in this case. (However, assigning "extra" variables in
+  # a Rails controller -- e.g., assigning `@foo`, then rendering a view that doesn't
+  # `need :foo` -- will never cause this error.)
+  #
+  # It can be useful to set this to :error if writing brand-new views (rather than translating
+  # old ERb views to Fortitude), since it will enforce cleaner code.
+  #
+  # There is a small speed penalty for setting this to `:use`.
+
+  # extra_assigns :ignore
+
+
+  # automatic_helper_access: default true
+  #
+  # If set to true, Fortitude's access to helpers works identically to ERb's -- i.e., you can
+  # use any helper in a Fortitude widget that would be accessible to an equivalent ERb view.
+  # If set to false, however, only helpers built-in to Rails and those you manually declare
+  # using `helper :foo` are accessible. This can be useful if starting to use Fortitude in
+  # a large, messy ERb/HAML/whatever codebase with many helpers, where you don't want new
+  # Fortitude code to start using a large variety of perhaps less-than-ideal helpers.
+
+  # automatic_helper_access true
+
+
+  # implicit_shared_variable_access: default false
+  #
+  # Rails ERb views use a giant bag of global state: not only can views access any `@foo`
+  # controller variable, but partials can, too, even if not passed to them -- and, even
+  # worse, they can _write_ to them. Fortitude disallows all of this by default; the only
+  # variables accessible to a Fortitude widget are those passed in directly and that it
+  # `:needs`. This results in vastly cleaner views. (If you really want to access such
+  # variables, even in Fortitude, they are available in a `shared_variables` `Hash`-like
+  # object that's accessible by widgets.)
+  #
+  # However, if you're translating legacy code from ERB/HAML/whatever to Fortitude, you may
+  # find that lots of code depends on this sort of action-at-a-distance, to the point where
+  # translating it is no longer feasible. If so, you can set `implicit_shared_variable_access`
+  # to `true`, and then you can read (and write!) any of these shared variables by simply
+  # using the normal syntax (`@foo`).
+  #
+  # There is a small speed penalty for enabling this.
+
+  # implicit_shared_variable_access false
+
+
+  # use_instance_variables_for_assigns: default false
+  #
+  # By default, parameters passed to a Fortitude widget are accessible using Ruby reader/
+  # method syntax (`foo`), and _not_ using Ruby instance-variable syntax (`@foo`). This
+  # has many advantages, not the least of which is that typos result in a clean exception
+  # instead of a "parameter" that happens to always be `nil`.
+  #
+  # However, if you're translating legacy code from ERB/HAML/whatever to Fortitude, you may
+  # find that lots of code depends on accessing parameters as instance variables. Setting
+  # this to `true` will expose parameters in both styles (`foo` and `@foo`). (Read, however,
+  # about `implicit_shared_variable_access`, above, too -- only by setting that also will
+  # Fortitude behave exactly like ERb in all such situations.)
+
+  # use_instance_variables_for_assigns false
+
+
+  # translation_base: default nil
+  #
+  # Rails' translation helper (usually called as `#t`, as in `t(:welcome_message)`) allows
+  # you to easily localize views. When called with a string starting with a dot,
+  # Rails normally prepends the view path to the key before looking it up -- for example,
+  # in app/views/foo/bar.html.rb, calling `t('.baz')` is equivalent to calling
+  # `t('foo.bar.baz'). However, in Fortitude, you can change this by setting `translation_base`
+  # to a string; this will prepend that string, before passing it onwards. (The
+  # `translation_base` string itself can even start with a dot, in which case it will be
+  # passed onwards to Rails' mechanism, which will then still add the view prefix before
+  # looking up the translation.)
+  #
+  # While generally not needed, this can be used to help clean up legacy applications with
+  # messy translations. For example, setting this to `fortitude.` will allow you to segregate
+  # all Fortitude translations under a top-level `fortitude` key, while setting it to
+  # `.fortitude.` will allow you to segregate each view's Fortitude translations under a
+  # Fortitude key underneath that view path.
+  #
+  # If this is used by any widget in the entire system, there is a small speed penalty applied
+  # to all calls of `#t` -- so only use this if you really need it.
+
+  # translation_base nil
+
+
+  # use_localized_content_methods: default false
+  #
+  # If set to true, then, if (for example) the locale is set to `fr`, Fortitude will look
+  # for a method in the widget called `#localized_content_fr`; if it exists, it will call
+  # that method _instead_ of `#content`. This provides support for views that may differ
+  # dramatically from one locale to the next.
+  #
+  # There is a very small speed penalty for any widget using this feature.
+
+  # use_localized_content_methods false
+end