Changelog History
Page 2
-
v0.0.7 Changes
November 12, 2014- Fortitude 0.0.6 introduced a regression, where referring to an autoloaded view class by partially-qualified namespace
path could cause an
Errno::ENOENT
exception indicating that a particular directory wasn't found.
- Fortitude 0.0.6 introduced a regression, where referring to an autoloaded view class by partially-qualified namespace
path could cause an
-
v0.0.6 Changes
November 11, 2014- ๐ Fixed an issue where naming a widget with an
.html.rb
extension (for example) at the end would work at first, but cause really irritating errors (likeuninitialized constant Views::Foo::Bar
apparently in the very file that definesViews::Foo::Bar
correctly inapp/views/foo/bar.html.rb
) when editing code in development mode. (Thanks to Jacob Maine for the very detailed bug report!) - ๐ Fixed an issue where trying to use Fortitude as a Tilt engine, but passing
nil
for thelocals
, would cause an exception. (Thanks to Roman Heinrich for reporting the bug!) - Using Fortitude as a template engine for mailers (
ActionMailer::Base
subclasses) now works. (Believe it or not, this was almost completely an issue of forgetting to support this, rather than it being undone — the code was complete, and it was just a matter of applying it toActionMailer::Base
as well asActionController::Base
.) (Thanks to Jacob Maine for the bug report and pull request!) - The various on-the-fly modules that Fortitude creates and mixes in to widgets (and define helpers, tag methods,
and
needs
methods) now all have actual names, which makes them much easier to identify in debugging printouts. - The code in
spec/
that knew how to reliably create, maintain, shut down, and otherwise manipulate an externalrails server
process has now been pulled out into its own gem,oop_rails_server
; this is so I can also use it with a new, closely-related upcoming project, and because reuse is good. ;) - โก๏ธ Updated the Travis configuration to the very latest Ruby and Rails versions.
- ๐ Fixed an issue where naming a widget with an
-
v0.0.5 Changes
September 22, 2014- You can now load both Fortitude and Erector at the same time into a project, and it will "just work": Erector
widgets will render using Erector, and Fortitude widgets will render using Fortitude. (Fortitude takes over the
actual template engine registration for
.rb
files, and uses a trick to keep Erector from displacing it; it then looks at the widget class being rendered, and delegates all Erector rendering directly to Erector.) - When inside a widget, you can now render a sub-widget using
widget MyWidget.new(...)
— i.e., passing an actual widget instance — or usingwidget MyWidget, { :param1 => value1 }
— i.e., passing a widget class and aHash
of assignments (which can be omitted if the widget doesn't have anyneed
s). - Fixed an issue where, e.g., calling
#render_to_string
on a Fortitude widget within a Rails controller, and then also rendering a Fortitude widget as the template for that action, would cause a method to be called onnil
. - โ Added
Fortitude::RenderingContext#parent_widget
, which returns the parent widget of the current widget during rendering at runtime. (In other words, this is not the superclass of the current widget, but the widget that caused this widget to get rendered, using eitherFortitude::Widget#widget
orrender :partial => ...
.) This can, of course, benil
if there is no current parent widget. - Added
Fortitude::Widget.all_fortitude_superclasses
, which returns anArray
of all superclasses of a widget up to, but not including,Fortitude::Widget
itself. - Added
Fortitude::Widget.widget_class_from_file
, which accepts the path to a file and an array of "root" directories to look under (i.e., assuming you're using something like Rails' autoloading mechanism), and returns theClass
object for the widget that's contained in that file. This uses a series of mechansims to try to detect the class that's present in the file: a "magic comment" that can be present in the file, an array of class names to try that you can pass in, the position of the class in the file hierarchy, and scanning the source text itself. - ๐ท Added a
record_tag_emission
class-level setting that tells a widget to call#emitting_tag!
on theFortitude::RenderingContext
when emitting a tag; you can use this to build various systems that need to know where in the hierarchy of tags we are at the moment. - The object being returned from Fortitude tag methods — which, in general, you should never use — now
inherits from
Object
, notBasicObject
, so that some built-in methods like#is_a?
can be safely called on it. This is for use in some users' environments doing funny things with the Ruby runtime that end up calling methods like that on the return values of widget#content
methods, which very often just end up being the tag return value object.
- You can now load both Fortitude and Erector at the same time into a project, and it will "just work": Erector
widgets will render using Erector, and Fortitude widgets will render using Fortitude. (Fortitude takes over the
actual template engine registration for
-
v0.0.4 Changes
June 24, 2014- โ Added support for building a JRuby-specific gem to the gemspec, so that things work smoothly for JRuby users. (Thanks, Ahto Jussila!)
โ Added preliminary support for inline widget classes: if you call
.inline_subclass
on any subclass ofFortitude::Widget
and pass a block, you'll get back a new subclass of whatever class you called it on, with acontent
method defined as per the block you passed. For example:my_widget_class = Fortitude::Widgets::Html5.inline_subclass do p "hello, world!" end my_widget_class.new.to_html # => 'hello, world!'
And, similarly, if you call
.inline_html
on any subclass ofFortitude::Widget
and pass a block, you'll get back the HTML rendered by the new subclass of that class. For example:html = Fortitude::Widgets::Html5.inline_html do p "hello, world!" end html # => 'hello, world!'
Note that this will not work on
Fortitude::Widget
, becauseFortitude::Widget
has nodoctype
declared, and therefore has no HTML tags available. You can either use one of the pre-made classes inFortitude::Widgets
, or, better yet, declare your own base widget class and then use.inline_subclass
and.inline_html
on that. (Using that mechanism, you can also set things likeformat_output
,start_and_end_comments
, and even things likeneeds
, mixing in or defining helper methods, and so on, and it will all work just fine.)
-
v0.0.3 Changes
June 23, 2014- ๐ Changed
Fortitude::Widget#to_html
to return the generated HTML. If you pass aFortitude::RenderingContext
into this method that has previously been used to render other HTML, you'll get all HTML (old and new) both, because we always append to a single output buffer — but that should be a corner case at most.
- ๐ Changed
-
v0.0.2 Changes
June 21, 2014- Void tags (those that can't take content, ever, like
<hr>
or<br>
) are now never closed in HTML4 doctypes (i.e., just output as plain<hr>
, with no close tag), since using self-closing syntax (<hr/>
) is broken and an end tag (</hr>
) is illegal according to the W3C Validator. In XHTML doctypes, they are always closed using self-closing syntax (<hr/>
) since they have to be closed somehow and that's a good way to indicate that they are void (can't ever take content). In HTML5, they are left unclosed by default (since HTML5 knows they're void and isn't expecting an end tag for them, ever), but you can useclose_void_tags true
to add self-closing syntax for them (<br/>
) if you want, since that is now allowed in HTML5. See this article for even more discussion. - Empty tags (those that can take content, but just happen not to) are now always closed using a separate tag
(e.g.,
<p></p>
), since it is not legal or correct to use self-closing syntax (<p/>
) here in HTML doctypes (HTML4 or HTML5), and it is perfectly legal in XHTML doctypes to use a separate closing tag — and, in a way, nice, since it lets you visually differentiate between void tags and normal tags that just happen to be empty. - ๐จ Very significant internal refactoring of code to make development easier, and new developers' lives easier.
- ๐ Fixed support for Tilt < 2.x; earlier Tilt versions expect to be able to instantiate a template class with an empty string and have it not raise an exception, as a way of testing whether an engine works. (Empty strings are not valid Fortitude templates, since we expect to see a class declaration in there.) Now we trap that case explicitly to do nothing, which allows Tilt 1.4.x to work.
- Void tags (those that can't take content, ever, like
-
v0.0.1 Changes
June 18, 2014- ๐ Very first release of Fortitude.