Changelog History
Page 1
-
v0.9.6 Changes
October 21, 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 yourrails generate
command line to switch back to ERb if desired.) Thanks to 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 usingsend
instead of calling it directly (e.g.,form_for(...) do |f|
, thenf.send(:text_field, ...)
instead off.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 for the bug report!)
- π Generator support: generation of controllers, mailers, and scaffolding will now produce nice Fortitude views
instead of ERb views. (You can add
-
v0.9.5 Changes
October 12, 2016- π Rails 5 compatibility: Fortitude now is fully compatible with Rails 5.0.0.1.
- π Significant improvements in performance to our dispatching to #t, the Rails method to produce translations of localized strings. Localized Rails applications tend to use this method a lot, so its performance can have a big impact on overall application performance.
- π A much better error message if you try to declare a method
static
when it hasn't been defined yet — this can often be the result of putting thestatic
declaration above the method definition in the source file, rather than below it. (Thanks totobymao
for the bug report!) - β‘οΈ Updated versions of Ruby and Rails that Travis CI tests against to the very latest.
- π Fixed an issue where Fortitude wasn't properly respecting Rails' view paths. Fortitude templates could be found at
alternate view paths, but our trick of namespacing views under
Views::
wouldn't apply. Now, it all works perfectly. (Thanks to Karl He for the bug report and example patch!) - π Fixed an issue where
#block_given?
always returnedtrue
inside a Fortitude widget's#content
method, whether a block was supplied to it or not. (Thanks to Jeff Dickey for the bug report!) - π Fixed an incompatibility between Fortitude and Rails 4.2.5.1, since Rails 4.2.5.1 added a fifth parameter to
ActionView::PathResolver#find_templates
. (Thanks to Luke Francl for the bug report!) - π Fixed incompatibilities with more-recently released versions of gems (
uglifier
,rake
,activesupport
) that otherwise broke compatibility with previous Ruby versions. - π Fixed an issue where Fortitudeβs system for figuring out what the name of a Fortitude widget would be, based on its
filename, could be confused by filenames ending in other extensions before
.rb
(for example,.html.rb
). - π Eliminated a deprecation warning from Rails 5 caused by Fortitude's use of
render :text
internally. - Removed usage of
alias_method_chain
on Ruby 2.0 and later, in favor ofModule#prepend
. This removes deprecation warnings otherwise triggered by Rails 5. (UsingModule#prepend
causes problems in JRuby, soalias_method_chain
is still used on JRuby instead.) - Changed the behavior of
automatic_helper_access false
so that, in a Rails application, it still makes all the built-in Rails helpers properly accessible, but does not make user-defined helpers accessible. (If there are even certain built-in Rails helpers you donβt want people using, you can easily override them in your widget class to raise an exception.) Without this,automatic_helper_access false
became so cumbersome to use that it was nearly pointless. (Thanks to Matt Walters for the pull request!) - Fixed an issue where explicitly declaring an assignment method as a helper (e.g.,
helper :foo=
) did not work properly. - Fixed an issue where passing a block to (e.g.)
f.label
, wheref
is the object yielded to aform_for
helper, did not work properly. (Thanks to Adam Becker for the bug report and test case!) - β¬οΈ Reduced escaping in attribute values: only
"
and&
need to be escaped, not<
,>
, or'
. (Thanks to Adam Becker for the bug report!) - π Fixed an issue where, under certain extremely rare circumstances, adding a view path in the controller (using
ActionView::ViewPaths.append_view_path
and related methods) would not be able to figure out the proper class name of the widget, and would fail. (Thanks to Leaf for the bug report!) - β Added the ability for the
inline_html
method on a widget class to accept aFortitude::RenderingContext
, thus allowing you to use it with code requiring access to helpers. (Thanks to Adam Becker for the bug report!)
-
v0.9.4 Changes
February 11, 2015- Fixed an issue where use of Rails'
form_for
orfields_for
from within anotherform_for
orfields_for
block would not produce the correct output. (Thanks to Leaf for the bug report!)
- Fixed an issue where use of Rails'
-
v0.9.3 Changes
February 03, 2015- π Fixed a memory leak when using
render :inline
, or certain other cases triggered by a user. (Fortitude widget classes know about all their subclasses, in order to enable proper propagation of configuration changes. If you created a subclass of a Fortitude widget that was intended to be single-use or otherwise temporary, it would not get garbage-collected, since its superclass would still maintain a reference to it. Fortitude now uses the ref gem in order to make this a weak reference, hence allowing it to be garbage-collected.render :inline
creates a temporary subclass of a Fortitude widget, thus triggering exactly this issue.)
- π Fixed a memory leak when using
-
v0.9.2 Changes
January 22, 2015- π 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. -
v0.9.1 Changes
December 15, 2014- π Fixed a bug where doing something like
div nil, :class => 'foo'
would simply output<div></div>
, rather than the desired<div class="foo"></div>
. (Thanks to Leaf for the bug report!) - You can now render widgets from ERb using a
widget
method, using the exact same syntax you would for rendering them from Fortitude. In addition, this works for Erector widgets, too. - Fixed a bug where calling
Fortitude::Widget.widget_class_from_file
would fail if the class name as specified in the source text of the file started with leading colons (e.g.,class ::Views::Foo
).
- π Fixed a bug where doing something like
-
v0.9.0 Changes
November 29, 2014β‘οΈ Updated Fortitude's version number to 0.9.0: at this point, Fortitude should be considered fully production-ready, as it is used successfully in multiple very large systems and bug reports are increasingly rare. I don't want to π release a 1.0 until there's excellent documentation, but the codebase seems to be ready.
- β Added explicit support for eager-loading Fortitude widget classes under
views/
for Rails applications. This both should improve first-run performance of Fortitude-using Rails applications in production, and should avoid an occasional problem where Fortitude widget classes were not properly loaded in environments that used eager loading, rather than autoloading, for classes.
- β Added explicit support for eager-loading Fortitude widget classes under
-
v0.0.10 Changes
November 25, 2014- π Fixed an issue where
#capture
was not working properly if you rendered a widget usingrender :widget =>
in a controller. The fix further simplifies Fortitude's support for that feature and integrates even more correctly with Rails in that way. (Thanks to Leaf for the bug report!) - π Fixed an issue where, if you overrode a "needs" method in a class, subclasses of that class would not use the overridden method, but instead access the "needs" method directly. (Thanks to Leaf for the bug report!)
- π Fixed a simple mistake that meant the module Fortitude uses to declare
needs
methods was not given a name at all, and instead the module it uses to declare helpers was given two names, one of them incorrect. (Thanks to Leaf for catching this.) - When you're invoking a widget from another widget using the
#widget
method, and you pass a block, that block is evaluated in the context of the parent widget. (This has always been true.) However, this meant that something like the following was impossible, where you're effectively defining new DSL on a widget-by-widget basis:
class Views::ModalDialog < Views::Base needs :title def content h3 "Modal: #{title}" yield button "Submit" end def modal_header(name) h5 "Modal header: #{name}" hr end end class Views::MyView < Views::Base needs :username def content h1 "User #{username}" widget Views::ModalDialog, :title => "User Settings" do modal_header "Settings for #{username}" input :type => :text, :name => :email ... end end end
The problem arises because, within the block in
Views::MyView#content
, you want to be able to access methods from two contexts: the parent widget (for#username
), and the child widget (for#modal_header
). Ruby provides no single, simple way to do this, but, without it, it's very difficult to come up with a truly elegant DSL for cases like this.Fortitude now supports this via a small bit of
method_missing
magic: the block passed to a widget is still evaluated in the context of the parent, but, if a method is called that is not present, Fortitude looks for that method in the child widget and invokes it there, if present. This allows the above situation, which is important for writing libraries that "feel right" to a Ruby programmer. (The fact that the block is evaluated primarily in the context of the parent widget, like all other Ruby blocks, preserves important standard Ruby semantics, and also means that the onus is on the author of a feature likeViews::ModalDialog
to present method names that are unlikely to conflict with those in use in parent widgets — which seems correct.)- You can now render Erector widgets from Fortitude widgets using just
widget MyErectorWidget
, and vice-versa, using either the class-and-assigns or instantiated-widget calling conventions. Note that this integration is not 100% perfect; in particular, passing a block from a Fortitude widget to an Erector widget, or vice-versa, is likely to fail or produce incorrect output due to the way Erector manipulates output buffers. However, the simple case of invoking a widget from another works fine, and can be very useful to those migrating to Fortitude. (Thanks to Adam Becker for the bug report!) - π Fixed an issue where Fortitude could write the close tag of an element to the wrong output buffer if the output
buffer was changed inside the element (as can happen with, among other things, Rails'
cache
method). This could cause the output HTML to be structured improperly. (Thanks to Leaf for the bug report,tracking down the exact cause, and providing the fix!)
- π Fixed an issue where
-
v0.0.9 Changes
November 20, 2014- π
Fortitude now supports passing blocks to widgets (above and beyond support for Rails' standard layouts and their
usage using
yield
). You can now do the following:
class Views::Foo < Views::Base def content p "something here" widget Views::Bar, :name => 'Yoko' { text "hello" } p "something else" end end class Views::Bar < Views::Base def content p "more content" yield p "even more content" end end
This will do as expected and cause
Views::Bar
'syield
call to call the block passed to it. Furthermore, because it's often very useful to break a widget down into methods, and you might not want to explicitly pass the block all over, you can callyield_from_widget
from any widget method and it will behave correctly. (This has actually always been true in Fortitude for yielding to layouts; it just now will also yield to blocks passed into the widget directly, too).Fortitude first prefers a block passed in to
#widget
; it then looks for a block passed to the constructor of a widget, and, finally, it will delegate to the layout (if any) if no other block is found. If there isn't even a layout, you will receive an error.Unlike Erector, Fortitude passes any arguments you give
yield
through to the widget, whether usingyield
oryield_from_widget
; it also passes, as the first argument, the widget instance being yielded from, too. This allows a more elegant solution to the fact that the block is evaluated in the scope of the caller, not the wiget, and thus may not have access to Fortitude methods (likep
,text
, and so on) if the caller is not itself a widget; you can simply call those methods on the passed-in widget instance.Thank you to Leaf for bringing up this issue!
The exact interpretation of attribute values has changed. Along with considerable discussion, it became clear that the most desirable behavior was the following: attributes with a value of
false
ornil
simply are not output at all (thus making behavior likeinput(:type => :checkbox, :checked => some_boolean_variable)
work properly); attributes with a value oftrue
are output as the key only (so the previous example becomes<input type="checkbox" checked>
ifsome_boolean_variable
istrue
) — except in XHTML document types, where that would be illegal, so they become (e.g.)<input type="checkbox" checked="checked">
; and attributes mapped to the empty string are output with a value of the empty string. Many thanks to Leaf and Adam Becker for all the discussion and validation around this!π Multiple huge performance increases in Fortitude's class-loading time for widgets. Fortitude internally uses dynamic compilation of many methods to achieve the very highest runtime performance; however, the system that did this compilation could cause slow startup times if you had a very large number of widgets. Fortitude now lazy- compiles some methods and caches its own internal trivial template language in order to make startup much faster without slowing down critical runtime performance. Many thanks to Leaf for reporting this issue and testing a number of fixes for it as they were made!
π Fixed a number of bugs in Fortitude's support for
render :widget => ...
, including use of helpers, coexistence with Erector, and being able to pass a widget class rather than an already-instantiated widget. Many thanks to Leaf for the detailed bug report, suggestions for fixes, and pointers to new methods that made the implementation much more robust.
- π
Fortitude now supports passing blocks to widgets (above and beyond support for Rails' standard layouts and their
usage using
-
v0.0.8 Changes
November 13, 2014- π Fixed an issue where repeated reloading of a view in development mode in Rails could cause an error of the form
superclass mismatch for class MyView
. (The issue was that Fortitude was callingrequire_dependency
on the view.rb
file in the template handler, which caused it to get loaded outside of the scope where Rails is watching for loaded constants, so that it can unload them before the next request. This caused view classes to hang around forever, but not necessarily their superclasses, causing a very confusingsuperclass mismatch
error.) Many thanks again to Jacob Maine for the very detailed bug report and collaboration to fix the issue.
- π Fixed an issue where repeated reloading of a view in development mode in Rails could cause an error of the form