Fortitude v0.9.2 Release Notes
Release Date: 2015-01-22 // over 9 years ago-
- ๐ Began writing lots of documentation for Fortitude, beginning with the reasons why you should use it.
- ๐ Fixed a single spec that caused failures under Rails 4.2.0 (which was an issue with the spec and something changed in Rails 4.2, not Fortitude).
- ๐ Fixed a bug where if you call
return
from inside a block passed to a tag method, the closing tags would not be output, resulting in invalid HTML. (Thanks to Leaf for the bug report!) - ๐ Fixed a bug where if you raised an exception from inside a block passed to a tag method, the closing tags would not be output, resulting in invalid HTML.
- โ Added a couple of missing
form_for
helper methods (button
,submit
) that somehow I missed. (Thanks to Leaf for the bug report!) - ๐ Fixed a bug where passing an object that was a
Hash
, or a subclass ofHash
, to a view would cause that object to become an object of classActiveSupport::HashWithIndifferentAccess
instead. (This was because we were, internally, calling#with_indifferent_access
on theHash
we had that contained all assignments to a widget, and#with_indifferent_access
is recursive.) Fortitude::Widget.widget_class_from_file
, when it cannot find a class in the given file, now returns any constants it did find matching names it thinks that file might use in the resulting exception. This can be used to, for example, determine if the file in question actually contains a module with the appropriate name, rather than a widget class.- When rendering using Tilt, Fortitude now properly supplies the file and line to the call to
eval
the source code of the widget. This, in turn, means that__FILE__
,__LINE__
, andcaller
will work properly when used at class level inside a widget rendered via Tilt. - Fixed a bug where
Fortitude::Widget.widget_class_from_file
andFortitude::Widget.widget_class_from_source
would, when scanning a file containing an ordinary class definition likemodule Foo; module Bar; class Baz < Fortitude::Widget
, instead return a classFoo::Baz
if such existed and was a descendant ofFortitude::Widget
instead of the correctFoo::Bar::Baz
. - ๐ Fixed a bug where, if
format_output
was turned on,<pre>
tags would still insert whitespace and newlines for formatting like any other tag — which is incorrect, because, only inside<pre>
tags, such whitespace is significant. Now,<pre>
tags correctly suppress all formatting within them. - Added
Fortitude::Widget#content_and_attributes_from_tag_arguments
; this takes as input any style of arguments permitted to a Fortitude tag method (e.g.,p
,p 'hello'
,p :id => :foo
,p 'hello', :id => :foo
) and always returns a two-element array — the first element is the text supplied to the method (if any), and the second is the attributes supplied to the method (if any), or an emptyHash
otherwise. This can help take a fair amount of bookkeeping burden off of helper methods you might build on top of Fortitude. - Added
Fortitude::Widget#add_css_classes
(a.k.a.#add_css_class
). This takes as its first argument one or more CSS classes to add (as aString
,Symbol
, orArray
of such), and, as its remainder, any arguments valid for a Fortitude tag method (e.g., textual content, aHash
of attributes, textual content and aHash
, or neither). It then returns a two-argument array of textual content and attributes; the attributes will have aclass
or:class
key that contains any classes specified in the original, plus the additional classes to add. In other words, you can use it as such:
def super_p(*args, &block) p(*add_css_classes(:super, *args), &block) end
...and now
super_p
acts just likep
, except that it adds a class ofsuper
to its output. This is an extremely common pattern in code built on top of Fortitude, and so now it is baked into the core.