fortitude 0.9.5-java → 0.9.6-java

Sign up to get free protection for your applications and to get access to all the features.
Files changed (34) hide show
  1. checksums.yaml +4 -4
  2. data/CHANGES.md +11 -0
  3. data/CONTRIBUTORS.md +4 -0
  4. data/fortitude.gemspec +1 -1
  5. data/lib/fortitude/rails/helpers.rb +20 -1
  6. data/lib/fortitude/rails/railtie.rb +2 -0
  7. data/lib/fortitude/rails/yielded_object_outputter.rb +3 -0
  8. data/lib/fortitude/version.rb +1 -1
  9. data/lib/fortitude/widget/integration.rb +15 -1
  10. data/lib/rails/generators/fortitude/base_view/base_view_generator.rb +13 -0
  11. data/lib/rails/generators/fortitude/base_view/templates/views_base.rb +230 -0
  12. data/lib/rails/generators/fortitude/controller/controller_generator.rb +18 -0
  13. data/lib/rails/generators/fortitude/controller/templates/view.html.rb +6 -0
  14. data/lib/rails/generators/fortitude/controller/templates/views_base.rb +230 -0
  15. data/lib/rails/generators/fortitude/mailer/mailer_generator.rb +26 -0
  16. data/lib/rails/generators/fortitude/mailer/templates/layout.html.rb +9 -0
  17. data/lib/rails/generators/fortitude/mailer/templates/view.html.rb +12 -0
  18. data/lib/rails/generators/fortitude/scaffold/scaffold_generator.rb +29 -0
  19. data/lib/rails/generators/fortitude/scaffold/templates/edit.html.rb +13 -0
  20. data/lib/rails/generators/fortitude/scaffold/templates/form.html.rb +44 -0
  21. data/lib/rails/generators/fortitude/scaffold/templates/index.html.rb +45 -0
  22. data/lib/rails/generators/fortitude/scaffold/templates/new.html.rb +11 -0
  23. data/lib/rails/generators/fortitude/scaffold/templates/show.html.rb +18 -0
  24. data/spec/rails/complex_helpers_system_spec.rb +6 -0
  25. data/spec/rails/data_passing_system_spec.rb +4 -0
  26. data/spec/rails/generators_system_spec.rb +166 -0
  27. data/spec/rails/templates/complex_helpers_system_spec/app/controllers/carryover_controller.rb +11 -0
  28. data/spec/rails/templates/complex_helpers_system_spec/app/views/carryover/show.html.rb +9 -0
  29. data/spec/rails/templates/complex_helpers_system_spec/app/views/complex_helpers_system_spec/form_for_test.rb +2 -0
  30. data/spec/rails/templates/complex_helpers_system_spec/config/routes.rb +6 -0
  31. data/spec/rails/templates/data_passing_system_spec/app/controllers/data_passing_system_spec_controller.rb +5 -0
  32. data/spec/rails/templates/data_passing_system_spec/app/views/data_passing_system_spec/nil_data_widget.rb +8 -0
  33. data/spec/rails/templates/generators_system_spec/config/environments/development.rb +39 -0
  34. metadata +30 -4
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: 6c0cdd4f8163e6329ea53df6eb0f3cdd0f7b462a
4
- data.tar.gz: e562cb7ca19a1fdb2ae5aad46045e44da00f9e7e
3
+ metadata.gz: 53c8bb7a7a3cf5effe1af6eea8b82d257151606d
4
+ data.tar.gz: 62b331d7eab7220f441ca68e622626ec88e45d15
5
5
  SHA512:
6
- metadata.gz: cab578b4fa509f130887152e3ee5f82784f436b02b9b2c12bd8d853e386954d5fba911ff646d1b95bb8849919f9f75dfc6606d9e5d9c7992008e284e65842141
7
- data.tar.gz: 5cdc304ee2ffec321ee2b6c316007208b043accc297b0e6299f5748889e919e3b8a9d29358c9745ef5b0d685c4c5181b1ee2a45d6f24e872955cfc11669ed98e
6
+ metadata.gz: 79389c098683a325bb8204d973f7f568a97e244a0da44d56fbb43682324f8cb0324948b171bd1e385c8c98bbf9ccf329e300bf125e26ec4bc41883d306517e9d
7
+ data.tar.gz: b63570ebefea3f89686b43d25e39fa4a0d7b1efb6bb0c8187f6ac3d231a740d13d6f5681eca222661e266b1670450d20635cf3514b6a5b5bf381d94d98acc68d
data/CHANGES.md CHANGED
@@ -1,5 +1,16 @@
1
1
  # Fortitude Releases
2
2
 
3
+ ## 0.9.6, 21 October 2016
4
+
5
+ * Generator support: generation of controllers, mailers, and scaffolding will now produce nice Fortitude views
6
+ instead of ERb views. (You can add `-e erb` to your `rails generate` command line to switch back to ERb if
7
+ desired.) Thanks to [Gaelan](https://github.com/Gaelan) for the suggestion!
8
+ * Fixed an issue where if you tried to invoke methods on the object yielded to a `form_for` call or similar
9
+ by using `send` instead of calling it directly (_e.g._, `form_for(...) do |f|`, then `f.send(:text_field, ...)`
10
+ instead of `f.text_field ...`), the method invocation would appear to be ignored.
11
+ * Fixed an issue where Rails `_url`/`_path` helpers didn't correctly pick up parameters set from the incoming
12
+ request. (Thanks to [Adam Becker](https://github.com/ajb) for the bug report!)
13
+
3
14
  ## 0.9.5, 12 October 2016
4
15
 
5
16
  * Rails 5 compatibility: Fortitude now is fully compatible with Rails 5.0.0.1.
data/CONTRIBUTORS.md CHANGED
@@ -54,6 +54,8 @@ Fortitude is written by [Andrew Geweke](https://github.com/ageweke), with contri
54
54
  (specifically, `<`, `>`, and `'`).
55
55
  * Reporting an issue where you couldn't use `inline_html` in a way that allowed you to pass a
56
56
  `Fortitude::RenderingContext`, thus preventing you from using it with code that required access to helpers.
57
+ * Reporting an issue where Rails' `_url`/`_path` helpers wouldn't pick up parameters set from the inbound request
58
+ correctly.
57
59
  * [Karl He](https://github.com/karlhe) for:
58
60
  * Reporting an issue (and supplying an example patch) where Fortitude wasn't respecting Rails' additional view
59
61
  paths correctly &mdash; only `app/views`.
@@ -67,3 +69,5 @@ Fortitude is written by [Andrew Geweke](https://github.com/ageweke), with contri
67
69
  * Fixes for compatibility with Rails 5.
68
70
  * [Matt Walters](https://github.com/mattwalters) for:
69
71
  * A patch to make built-in Rails helpers work even when `automatic_helper_access` was set to `false`.
72
+ * [Gaelan](https://github.com/Gaelan) for:
73
+ * Suggesting generator support for Fortitude.
data/fortitude.gemspec CHANGED
@@ -52,7 +52,7 @@ Gem::Specification.new do |s|
52
52
  s.add_development_dependency "rspec", "~> 2.99"
53
53
  s.add_development_dependency "rake-compiler"
54
54
  s.add_development_dependency "tilt", "~> 2.0"
55
- s.add_development_dependency "oop_rails_server", ">= 0.0.22"
55
+ s.add_development_dependency "oop_rails_server", ">= 0.0.24"
56
56
 
57
57
  # This is because i18n >= 0.7 is incompatible with Ruby 1.8.x.
58
58
  if RUBY_VERSION =~ /^1\.8\./
@@ -12,10 +12,24 @@ module Fortitude
12
12
  end
13
13
 
14
14
  def apply_refined_helpers_to!(o)
15
- o.send(:include, ::Rails.application.routes.url_helpers)
16
15
  @helpers.each do |name, options|
17
16
  o.helper(name, options)
18
17
  end
18
+
19
+ url_helpers_module = ::Rails.application.routes.url_helpers
20
+
21
+ test_base_class = Class.new
22
+ test_base_instance = test_base_class.new
23
+
24
+ test_class = Class.new
25
+ test_class.send(:include, url_helpers_module)
26
+ test_instance = test_class.new
27
+
28
+ metaclass = o.instance_eval("class << self; self; end")
29
+
30
+ metaclass.send(:define_method, :_fortitude_allow_helper_even_without_automatic_helper_access?) do |method_name|
31
+ test_instance.respond_to?(method_name) && (! test_base_instance.respond_to?(method_name))
32
+ end
19
33
  end
20
34
 
21
35
  ALL_BUILTIN_HELPER_MODULES = {
@@ -45,6 +59,11 @@ module Fortitude
45
59
  }
46
60
  }
47
61
 
62
+ # We could use the mechanism used above for the url_helpers_module, but this makes access to these helpers
63
+ # much faster -- they end up with real methods defined for them, instead of using method_missing magic
64
+ # every time. We don't necessarily want to do that for the url_helpers_module, because there can be tons and
65
+ # tons of methods in there...and because we initialize early-enough on that methods aren't defined there yet,
66
+ # anyway.
48
67
  def declare_all_builtin_rails_helpers!
49
68
  ALL_BUILTIN_HELPER_MODULES.each do |base_module, constant_names|
50
69
  constant_names.each do |constant_name|
@@ -25,6 +25,8 @@ end
25
25
  module Fortitude
26
26
  module Rails
27
27
  class Railtie < ::Rails::Railtie
28
+ config.app_generators.template_engine :fortitude
29
+
28
30
  class << self
29
31
  def _fortitude_view_roots
30
32
  @_fortitude_view_roots_mutex.synchronize do
@@ -29,6 +29,9 @@ module Fortitude
29
29
  EMPTY_RETURN_VALUE = ''.freeze
30
30
 
31
31
  def method_missing(method_name, *args, &block)
32
+ method_name = method_name.to_sym
33
+ method_name = args.shift if method_name == :send
34
+
32
35
  if @method_names_hash[method_name.to_sym]
33
36
  block = ::Fortitude::Rails::YieldedObjectOutputter.wrap_block_as_needed(@output_target, method_name, block, @method_names_hash.keys)
34
37
  return_value = @yielded_object.send(method_name, *args, &block)
@@ -1,3 +1,3 @@
1
1
  module Fortitude
2
- VERSION = "0.9.5"
2
+ VERSION = "0.9.6"
3
3
  end
@@ -56,13 +56,27 @@ module Fortitude
56
56
  out
57
57
  end
58
58
 
59
+ def _fortitude_use_helper?(method_name)
60
+ unless @_fortitude_rendering_context && @_fortitude_rendering_context.helpers_object && @_fortitude_rendering_context.helpers_object.respond_to?(method_name, true)
61
+ return false
62
+ end
63
+
64
+ return self.class.automatic_helper_access ||
65
+ (self.class.respond_to?(:_fortitude_allow_helper_even_without_automatic_helper_access?) &&
66
+ self.class._fortitude_allow_helper_even_without_automatic_helper_access?(method_name))
67
+ end
68
+
69
+ def _fortitude_allow_helper_even_without_automatic_helper_access?(method_name)
70
+ false
71
+ end
72
+
59
73
  def _fortitude_target_method_and_args_for_method_missing(missing_method_name, *missing_method_args, &missing_method_block)
60
74
  if self.class.extra_assigns == :use && missing_method_args.length == 0 && (! missing_method_block)
61
75
  ivar_name = self.class.instance_variable_name_for_need(missing_method_name)
62
76
  return [ self, :instance_variable_get, ivar_name ] if instance_variable_defined?(ivar_name)
63
77
  end
64
78
 
65
- 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)
79
+ if _fortitude_use_helper?(missing_method_name)
66
80
  return [ @_fortitude_rendering_context.helpers_object, missing_method_name, *missing_method_args ]
67
81
  end
68
82
 
@@ -0,0 +1,13 @@
1
+ require 'rails/generators/erb/controller/controller_generator'
2
+
3
+ module Fortitude
4
+ module Generators
5
+ class BaseViewGenerator < ::Rails::Generators::Base
6
+ source_root File.join(File.dirname(__FILE__), 'templates')
7
+
8
+ def create_view_base
9
+ template "views_base.rb", 'app/views/base.rb', :skip => true
10
+ end
11
+ end
12
+ end
13
+ end
@@ -0,0 +1,230 @@
1
+ class Views::Base < Fortitude::Widget
2
+ # You can configure the behavior of Fortitude in this file.
3
+ #
4
+ # Don't be afraid -- by default you can simply ignore this file, and probably everything will
5
+ # work exactly as you'd expect. Come back to it if you want to tweak Fortitude's behavior or
6
+ # read about some of its more interesting features.
7
+ #
8
+ #
9
+ # Fortitude configuration options apply to the class they're invoked on, and all subclasses.
10
+ # By convention, app/views/base.rb holds Views::Base, which is used as the superclass of all
11
+ # Fortitude widgets in a Rails application -- thus, configuration set here will apply to all
12
+ # Fortitude widgets. However, you can create any subclasses of this class you want, and set
13
+ # different configuration there, which will apply to all subclasses of those widgets.
14
+ # (For example, you could create app/views/admin/base.rb containing
15
+ # Views::Admin::Base < Views::Base, and set configuration there that would only apply to any
16
+ # widget inheriting from Views::Admin::Base). The only exception is `doctype`, which cannot
17
+ # be set on the descendant of any class that's set it itself.
18
+ #
19
+ # Below are all the current Fortitude configuration options, as of the creation of this file.
20
+
21
+
22
+ # This controls the set of tags available to you (and the nesting and attributes they allow,
23
+ # if you enable enforce_element_nesting_rules or enforce_attribute_rules). It also controls
24
+ # what the `doctype!` method outputs, and related behavior (such as how self-closing elements
25
+ # like <br> render).
26
+ #
27
+ # You can choose from :html5, :html4_transitional, :html4_strict, :html4_frameset,
28
+ # :xhtml11, :xhtml10_transitional, :xhtml10_strict, and :xhtml10_frameset.
29
+ doctype :html5
30
+
31
+
32
+
33
+ # format_output: default true in development mode, false otherwise
34
+ #
35
+ # format_output causes the output of "pretty-printed" HTML, beautifully nested and easy for
36
+ # humans to read. If set to false, HTML is produced with as little whitespace as possible
37
+ # while preserving meaning -- better for production, where minimizing size of generated HTML
38
+ # is more important.
39
+
40
+ # format_output (!! Rails.env.development?)
41
+
42
+
43
+ # start_and_end_comments: default true in development mode, false otherwise
44
+ #
45
+ # start_and_end_comments causes comments to be written into the HTML at the start and end
46
+ # of every widget rendered, showing the class name of the widget, its nesting depth, and
47
+ # all the arguments passed to that widget. This makes it vastly easier to look at the HTML
48
+ # generated for an entire page and know exactly which view file to go change in order to
49
+ # change that HTML.
50
+
51
+ # start_and_end_comments (!! Rails.env.development?)
52
+
53
+
54
+ # debug: default true in development mode, false otherwise
55
+ #
56
+ # debug alerts you when a rare, but extremely-difficult-to-debug, situation arises.
57
+ # Fortitude prioritizes parameters declared using 'need' above its built-in HTML tags.
58
+ # As an example, if you pass a parameter called `time` to your view by saying
59
+ # `needs :time`, then the method `time` in your widget will return the value of that
60
+ # attribute, rather than (as it otherwise would) rendering the HTML5 `<time>` tag.
61
+ # This is fine (and you can always use `tag_time` to get the HTML5 tag).
62
+ #
63
+ # But say you forget, imagine it's the tag, and write the following:
64
+ # time { p "this is the time" } (or something similar). Because time is now a method
65
+ # that simply returns the value of the `time` parameter, this code will do absolutely
66
+ # nothing -- it's throwing away the block passed to it, returning the `time` parameter,
67
+ # and outputting nothing. Needless to say, this can be extremely frustrating to debug.
68
+ #
69
+ # If `debug` is true, then, the code above will raise an exception
70
+ # (Fortitude::Errors::BlockPassedToNeedMethod) instead of ignoring the block, and it'll be
71
+ # dramatically easier to debug.
72
+
73
+ # debug (!! Rails.env.development?)
74
+
75
+
76
+ # enforce_element_nesting_rules: default false
77
+ #
78
+ # If set to true, Fortitude will require you to respect the HTML element-nesting rules
79
+ # (for example, you can't put a <div> inside a <p>), and will raise an exception
80
+ # (Fortitude::Errors::InvalidElementNesting) if you do something the HTML spec disallows.
81
+ # This can be extremely useful in helping you to write clean HTML.
82
+ #
83
+ # There is a small speed penalty for turning this on, so it's recommended you only enable
84
+ # it in development mode.
85
+
86
+ # enforce_element_nesting_rules false
87
+
88
+
89
+ # enforce_attribute_rules: default false
90
+ #
91
+ # If set to true, Fortitude will prevent you from using any attribute that isn't defined
92
+ # in the HTML spec, and will raise a Fortitude::Errors::InvalidElementAttributes error
93
+ # if you do otherwise. (Note that any attribute starting with 'data-' or 'aria-' is allowed,
94
+ # since that's in the spec.) This can be extremely useful in helping you to write clean
95
+ # HTML.
96
+ #
97
+ # There is a small speed penalty for turning this on, so it's recommended you only enable
98
+ # it in development mode.
99
+
100
+ # enforce_attribute_rules false
101
+
102
+
103
+ # enforce_id_uniqueness: default false
104
+ #
105
+ # If set to true, Fortitude will prevent you from giving multiple elements the same 'id'
106
+ # on a page, and will raise a Fortitude::Errors::DuplicateId if you do. This can be
107
+ # extremely useful in helping you to write clean HTML.
108
+ #
109
+ # There is a small speed penalty for turning this on, so it's recommended you only enable
110
+ # it in development mode.
111
+
112
+ # enforce_id_uniqueness false
113
+
114
+
115
+ # close_void_tags: default false
116
+ #
117
+ # In HTML5, "self-closing" tags like `<br>` can be written as `<br>` or `<br/>`; either is
118
+ # legal. (In HTML4, `<br/>` is not legal, and neither is `<br></br>`. In XML, `<br/>` or
119
+ # `<br></br>` is mandatory.) By default, Fortitude will output `<br>`. However, if you set
120
+ # `close_void_tags` to true, then Fortitude will output `<br/>`, instead. Attempting to
121
+ # change this to true in a HTML4 doctype or false for an XHTML doctype will result in an
122
+ # error.
123
+
124
+ # close_void_tags false
125
+
126
+
127
+ # extra_assigns: default :ignore
128
+ #
129
+ # This controls what happens if you pass parameters to a widget that it hasn't declared a
130
+ # `need` for. If set to `:ignore`, it will simply ignore them; they will not be available to
131
+ # the widget to use. If set to `:use`, it will make them available for use in the widget --
132
+ # this is not recommended, however; it's better for the widget to declare all parameters
133
+ # it possibly could use, giving them defaults, instead of making undeclared parameters
134
+ # magically accessible. If set to `:error`, Fortitude will raise a
135
+ # Fortitude::Errors::ExtraAssigns in this case. (However, assigning "extra" variables in
136
+ # a Rails controller -- e.g., assigning `@foo`, then rendering a view that doesn't
137
+ # `need :foo` -- will never cause this error.)
138
+ #
139
+ # It can be useful to set this to :error if writing brand-new views (rather than translating
140
+ # old ERb views to Fortitude), since it will enforce cleaner code.
141
+ #
142
+ # There is a small speed penalty for setting this to `:use`.
143
+
144
+ # extra_assigns :ignore
145
+
146
+
147
+ # automatic_helper_access: default true
148
+ #
149
+ # If set to true, Fortitude's access to helpers works identically to ERb's -- i.e., you can
150
+ # use any helper in a Fortitude widget that would be accessible to an equivalent ERb view.
151
+ # If set to false, however, only helpers built-in to Rails and those you manually declare
152
+ # using `helper :foo` are accessible. This can be useful if starting to use Fortitude in
153
+ # a large, messy ERb/HAML/whatever codebase with many helpers, where you don't want new
154
+ # Fortitude code to start using a large variety of perhaps less-than-ideal helpers.
155
+
156
+ # automatic_helper_access true
157
+
158
+
159
+ # implicit_shared_variable_access: default false
160
+ #
161
+ # Rails ERb views use a giant bag of global state: not only can views access any `@foo`
162
+ # controller variable, but partials can, too, even if not passed to them -- and, even
163
+ # worse, they can _write_ to them. Fortitude disallows all of this by default; the only
164
+ # variables accessible to a Fortitude widget are those passed in directly and that it
165
+ # `:needs`. This results in vastly cleaner views. (If you really want to access such
166
+ # variables, even in Fortitude, they are available in a `shared_variables` `Hash`-like
167
+ # object that's accessible by widgets.)
168
+ #
169
+ # However, if you're translating legacy code from ERB/HAML/whatever to Fortitude, you may
170
+ # find that lots of code depends on this sort of action-at-a-distance, to the point where
171
+ # translating it is no longer feasible. If so, you can set `implicit_shared_variable_access`
172
+ # to `true`, and then you can read (and write!) any of these shared variables by simply
173
+ # using the normal syntax (`@foo`).
174
+ #
175
+ # There is a small speed penalty for enabling this.
176
+
177
+ # implicit_shared_variable_access false
178
+
179
+
180
+ # use_instance_variables_for_assigns: default false
181
+ #
182
+ # By default, parameters passed to a Fortitude widget are accessible using Ruby reader/
183
+ # method syntax (`foo`), and _not_ using Ruby instance-variable syntax (`@foo`). This
184
+ # has many advantages, not the least of which is that typos result in a clean exception
185
+ # instead of a "parameter" that happens to always be `nil`.
186
+ #
187
+ # However, if you're translating legacy code from ERB/HAML/whatever to Fortitude, you may
188
+ # find that lots of code depends on accessing parameters as instance variables. Setting
189
+ # this to `true` will expose parameters in both styles (`foo` and `@foo`). (Read, however,
190
+ # about `implicit_shared_variable_access`, above, too -- only by setting that also will
191
+ # Fortitude behave exactly like ERb in all such situations.)
192
+
193
+ # use_instance_variables_for_assigns false
194
+
195
+
196
+ # translation_base: default nil
197
+ #
198
+ # Rails' translation helper (usually called as `#t`, as in `t(:welcome_message)`) allows
199
+ # you to easily localize views. When called with a string starting with a dot,
200
+ # Rails normally prepends the view path to the key before looking it up -- for example,
201
+ # in app/views/foo/bar.html.rb, calling `t('.baz')` is equivalent to calling
202
+ # `t('foo.bar.baz'). However, in Fortitude, you can change this by setting `translation_base`
203
+ # to a string; this will prepend that string, before passing it onwards. (The
204
+ # `translation_base` string itself can even start with a dot, in which case it will be
205
+ # passed onwards to Rails' mechanism, which will then still add the view prefix before
206
+ # looking up the translation.)
207
+ #
208
+ # While generally not needed, this can be used to help clean up legacy applications with
209
+ # messy translations. For example, setting this to `fortitude.` will allow you to segregate
210
+ # all Fortitude translations under a top-level `fortitude` key, while setting it to
211
+ # `.fortitude.` will allow you to segregate each view's Fortitude translations under a
212
+ # Fortitude key underneath that view path.
213
+ #
214
+ # If this is used by any widget in the entire system, there is a small speed penalty applied
215
+ # to all calls of `#t` -- so only use this if you really need it.
216
+
217
+ # translation_base nil
218
+
219
+
220
+ # use_localized_content_methods: default false
221
+ #
222
+ # If set to true, then, if (for example) the locale is set to `fr`, Fortitude will look
223
+ # for a method in the widget called `#localized_content_fr`; if it exists, it will call
224
+ # that method _instead_ of `#content`. This provides support for views that may differ
225
+ # dramatically from one locale to the next.
226
+ #
227
+ # There is a very small speed penalty for any widget using this feature.
228
+
229
+ # use_localized_content_methods false
230
+ end
@@ -0,0 +1,18 @@
1
+ require 'rails/generators/erb/controller/controller_generator'
2
+
3
+ module Fortitude
4
+ module Generators
5
+ class ControllerGenerator < Erb::Generators::ControllerGenerator
6
+ source_root File.join(File.dirname(__FILE__), 'templates')
7
+
8
+ def create_view_base
9
+ generate "fortitude:base_view"
10
+ end
11
+
12
+ protected
13
+ def handler
14
+ :rb
15
+ end
16
+ end
17
+ end
18
+ end
@@ -0,0 +1,6 @@
1
+ class Views::<%= class_name.camelize %>::<%= @action.camelize %> < Views::Base
2
+ def content
3
+ h1 "<%= class_name %>#<%= @action %>"
4
+ p "Find me in <%= @path %>"
5
+ end
6
+ end
@@ -0,0 +1,230 @@
1
+ class Views::Base < Fortitude::Widget
2
+ # You can configure the behavior of Fortitude in this file.
3
+ #
4
+ # Don't be afraid -- by default you can simply ignore this file, and probably everything will
5
+ # work exactly as you'd expect. Come back to it if you want to tweak Fortitude's behavior or
6
+ # read about some of its more interesting features.
7
+ #
8
+ #
9
+ # Fortitude configuration options apply to the class they're invoked on, and all subclasses.
10
+ # By convention, app/views/base.rb holds Views::Base, which is used as the superclass of all
11
+ # Fortitude widgets in a Rails application -- thus, configuration set here will apply to all
12
+ # Fortitude widgets. However, you can create any subclasses of this class you want, and set
13
+ # different configuration there, which will apply to all subclasses of those widgets.
14
+ # (For example, you could create app/views/admin/base.rb containing
15
+ # Views::Admin::Base < Views::Base, and set configuration there that would only apply to any
16
+ # widget inheriting from Views::Admin::Base). The only exception is `doctype`, which cannot
17
+ # be set on the descendant of any class that's set it itself.
18
+ #
19
+ # Below are all the current Fortitude configuration options, as of the creation of this file.
20
+
21
+
22
+ # This controls the set of tags available to you (and the nesting and attributes they allow,
23
+ # if you enable enforce_element_nesting_rules or enforce_attribute_rules). It also controls
24
+ # what the `doctype!` method outputs, and related behavior (such as how self-closing elements
25
+ # like <br> render).
26
+ #
27
+ # You can choose from :html5, :html4_transitional, :html4_strict, :html4_frameset,
28
+ # :xhtml11, :xhtml10_transitional, :xhtml10_strict, and :xhtml10_frameset.
29
+ doctype :html5
30
+
31
+
32
+
33
+ # format_output: default true in development mode, false otherwise
34
+ #
35
+ # format_output causes the output of "pretty-printed" HTML, beautifully nested and easy for
36
+ # humans to read. If set to false, HTML is produced with as little whitespace as possible
37
+ # while preserving meaning -- better for production, where minimizing size of generated HTML
38
+ # is more important.
39
+
40
+ # format_output (!! Rails.env.development?)
41
+
42
+
43
+ # start_and_end_comments: default true in development mode, false otherwise
44
+ #
45
+ # start_and_end_comments causes comments to be written into the HTML at the start and end
46
+ # of every widget rendered, showing the class name of the widget, its nesting depth, and
47
+ # all the arguments passed to that widget. This makes it vastly easier to look at the HTML
48
+ # generated for an entire page and know exactly which view file to go change in order to
49
+ # change that HTML.
50
+
51
+ # start_and_end_comments (!! Rails.env.development?)
52
+
53
+
54
+ # debug: default true in development mode, false otherwise
55
+ #
56
+ # debug alerts you when a rare, but extremely-difficult-to-debug, situation arises.
57
+ # Fortitude prioritizes parameters declared using 'need' above its built-in HTML tags.
58
+ # As an example, if you pass a parameter called `time` to your view by saying
59
+ # `needs :time`, then the method `time` in your widget will return the value of that
60
+ # attribute, rather than (as it otherwise would) rendering the HTML5 `<time>` tag.
61
+ # This is fine (and you can always use `tag_time` to get the HTML5 tag).
62
+ #
63
+ # But say you forget, imagine it's the tag, and write the following:
64
+ # time { p "this is the time" } (or something similar). Because time is now a method
65
+ # that simply returns the value of the `time` parameter, this code will do absolutely
66
+ # nothing -- it's throwing away the block passed to it, returning the `time` parameter,
67
+ # and outputting nothing. Needless to say, this can be extremely frustrating to debug.
68
+ #
69
+ # If `debug` is true, then, the code above will raise an exception
70
+ # (Fortitude::Errors::BlockPassedToNeedMethod) instead of ignoring the block, and it'll be
71
+ # dramatically easier to debug.
72
+
73
+ # debug (!! Rails.env.development?)
74
+
75
+
76
+ # enforce_element_nesting_rules: default false
77
+ #
78
+ # If set to true, Fortitude will require you to respect the HTML element-nesting rules
79
+ # (for example, you can't put a <div> inside a <p>), and will raise an exception
80
+ # (Fortitude::Errors::InvalidElementNesting) if you do something the HTML spec disallows.
81
+ # This can be extremely useful in helping you to write clean HTML.
82
+ #
83
+ # There is a small speed penalty for turning this on, so it's recommended you only enable
84
+ # it in development mode.
85
+
86
+ # enforce_element_nesting_rules false
87
+
88
+
89
+ # enforce_attribute_rules: default false
90
+ #
91
+ # If set to true, Fortitude will prevent you from using any attribute that isn't defined
92
+ # in the HTML spec, and will raise a Fortitude::Errors::InvalidElementAttributes error
93
+ # if you do otherwise. (Note that any attribute starting with 'data-' or 'aria-' is allowed,
94
+ # since that's in the spec.) This can be extremely useful in helping you to write clean
95
+ # HTML.
96
+ #
97
+ # There is a small speed penalty for turning this on, so it's recommended you only enable
98
+ # it in development mode.
99
+
100
+ # enforce_attribute_rules false
101
+
102
+
103
+ # enforce_id_uniqueness: default false
104
+ #
105
+ # If set to true, Fortitude will prevent you from giving multiple elements the same 'id'
106
+ # on a page, and will raise a Fortitude::Errors::DuplicateId if you do. This can be
107
+ # extremely useful in helping you to write clean HTML.
108
+ #
109
+ # There is a small speed penalty for turning this on, so it's recommended you only enable
110
+ # it in development mode.
111
+
112
+ # enforce_id_uniqueness false
113
+
114
+
115
+ # close_void_tags: default false
116
+ #
117
+ # In HTML5, "self-closing" tags like `<br>` can be written as `<br>` or `<br/>`; either is
118
+ # legal. (In HTML4, `<br/>` is not legal, and neither is `<br></br>`. In XML, `<br/>` or
119
+ # `<br></br>` is mandatory.) By default, Fortitude will output `<br>`. However, if you set
120
+ # `close_void_tags` to true, then Fortitude will output `<br/>`, instead. Attempting to
121
+ # change this to true in a HTML4 doctype or false for an XHTML doctype will result in an
122
+ # error.
123
+
124
+ # close_void_tags false
125
+
126
+
127
+ # extra_assigns: default :ignore
128
+ #
129
+ # This controls what happens if you pass parameters to a widget that it hasn't declared a
130
+ # `need` for. If set to `:ignore`, it will simply ignore them; they will not be available to
131
+ # the widget to use. If set to `:use`, it will make them available for use in the widget --
132
+ # this is not recommended, however; it's better for the widget to declare all parameters
133
+ # it possibly could use, giving them defaults, instead of making undeclared parameters
134
+ # magically accessible. If set to `:error`, Fortitude will raise a
135
+ # Fortitude::Errors::ExtraAssigns in this case. (However, assigning "extra" variables in
136
+ # a Rails controller -- e.g., assigning `@foo`, then rendering a view that doesn't
137
+ # `need :foo` -- will never cause this error.)
138
+ #
139
+ # It can be useful to set this to :error if writing brand-new views (rather than translating
140
+ # old ERb views to Fortitude), since it will enforce cleaner code.
141
+ #
142
+ # There is a small speed penalty for setting this to `:use`.
143
+
144
+ # extra_assigns :ignore
145
+
146
+
147
+ # automatic_helper_access: default true
148
+ #
149
+ # If set to true, Fortitude's access to helpers works identically to ERb's -- i.e., you can
150
+ # use any helper in a Fortitude widget that would be accessible to an equivalent ERb view.
151
+ # If set to false, however, only helpers built-in to Rails and those you manually declare
152
+ # using `helper :foo` are accessible. This can be useful if starting to use Fortitude in
153
+ # a large, messy ERb/HAML/whatever codebase with many helpers, where you don't want new
154
+ # Fortitude code to start using a large variety of perhaps less-than-ideal helpers.
155
+
156
+ # automatic_helper_access true
157
+
158
+
159
+ # implicit_shared_variable_access: default false
160
+ #
161
+ # Rails ERb views use a giant bag of global state: not only can views access any `@foo`
162
+ # controller variable, but partials can, too, even if not passed to them -- and, even
163
+ # worse, they can _write_ to them. Fortitude disallows all of this by default; the only
164
+ # variables accessible to a Fortitude widget are those passed in directly and that it
165
+ # `:needs`. This results in vastly cleaner views. (If you really want to access such
166
+ # variables, even in Fortitude, they are available in a `shared_variables` `Hash`-like
167
+ # object that's accessible by widgets.)
168
+ #
169
+ # However, if you're translating legacy code from ERB/HAML/whatever to Fortitude, you may
170
+ # find that lots of code depends on this sort of action-at-a-distance, to the point where
171
+ # translating it is no longer feasible. If so, you can set `implicit_shared_variable_access`
172
+ # to `true`, and then you can read (and write!) any of these shared variables by simply
173
+ # using the normal syntax (`@foo`).
174
+ #
175
+ # There is a small speed penalty for enabling this.
176
+
177
+ # implicit_shared_variable_access false
178
+
179
+
180
+ # use_instance_variables_for_assigns: default false
181
+ #
182
+ # By default, parameters passed to a Fortitude widget are accessible using Ruby reader/
183
+ # method syntax (`foo`), and _not_ using Ruby instance-variable syntax (`@foo`). This
184
+ # has many advantages, not the least of which is that typos result in a clean exception
185
+ # instead of a "parameter" that happens to always be `nil`.
186
+ #
187
+ # However, if you're translating legacy code from ERB/HAML/whatever to Fortitude, you may
188
+ # find that lots of code depends on accessing parameters as instance variables. Setting
189
+ # this to `true` will expose parameters in both styles (`foo` and `@foo`). (Read, however,
190
+ # about `implicit_shared_variable_access`, above, too -- only by setting that also will
191
+ # Fortitude behave exactly like ERb in all such situations.)
192
+
193
+ # use_instance_variables_for_assigns false
194
+
195
+
196
+ # translation_base: default nil
197
+ #
198
+ # Rails' translation helper (usually called as `#t`, as in `t(:welcome_message)`) allows
199
+ # you to easily localize views. When called with a string starting with a dot,
200
+ # Rails normally prepends the view path to the key before looking it up -- for example,
201
+ # in app/views/foo/bar.html.rb, calling `t('.baz')` is equivalent to calling
202
+ # `t('foo.bar.baz'). However, in Fortitude, you can change this by setting `translation_base`
203
+ # to a string; this will prepend that string, before passing it onwards. (The
204
+ # `translation_base` string itself can even start with a dot, in which case it will be
205
+ # passed onwards to Rails' mechanism, which will then still add the view prefix before
206
+ # looking up the translation.)
207
+ #
208
+ # While generally not needed, this can be used to help clean up legacy applications with
209
+ # messy translations. For example, setting this to `fortitude.` will allow you to segregate
210
+ # all Fortitude translations under a top-level `fortitude` key, while setting it to
211
+ # `.fortitude.` will allow you to segregate each view's Fortitude translations under a
212
+ # Fortitude key underneath that view path.
213
+ #
214
+ # If this is used by any widget in the entire system, there is a small speed penalty applied
215
+ # to all calls of `#t` -- so only use this if you really need it.
216
+
217
+ # translation_base nil
218
+
219
+
220
+ # use_localized_content_methods: default false
221
+ #
222
+ # If set to true, then, if (for example) the locale is set to `fr`, Fortitude will look
223
+ # for a method in the widget called `#localized_content_fr`; if it exists, it will call
224
+ # that method _instead_ of `#content`. This provides support for views that may differ
225
+ # dramatically from one locale to the next.
226
+ #
227
+ # There is a very small speed penalty for any widget using this feature.
228
+
229
+ # use_localized_content_methods false
230
+ end