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 of Hash, to a view would cause that object to become an object of class ActiveSupport::HashWithIndifferentAccess instead. (This was because we were, internally, calling #with_indifferent_access on the Hash 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__, and caller will work properly when used at class level inside a widget rendered via Tilt.
    • Fixed a bug where Fortitude::Widget.widget_class_from_file and Fortitude::Widget.widget_class_from_source would, when scanning a file containing an ordinary class definition like module Foo; module Bar; class Baz < Fortitude::Widget, instead return a class Foo::Baz if such existed and was a descendant of Fortitude::Widget instead of the correct Foo::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 empty Hash 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 a String, Symbol, or Array of such), and, as its remainder, any arguments valid for a Fortitude tag method (e.g., textual content, a Hash of attributes, textual content and a Hash, or neither). It then returns a two-argument array of textual content and attributes; the attributes will have a class 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 like p, except that it adds a class of super 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.