[rspec-users] HTML Story Formatter
ben at benmabey.com
Sat Jul 26 18:38:35 EDT 2008
David Chelimsky wrote:
> On Fri, Jul 25, 2008 at 8:08 AM, Joseph Wilk <lists at ruby-forum.com>
>> To handle this I wrote a patch which delivered the styles in the html
formatters output. In much the same way as the html spec formatter
>> I know Aslak Hellesøy has been looking at the editable html stories. Is
it acceptable to have stories have styles embedded in the html
formatter until Aslak's editable stories project evolves?
>> I could imagine there are some arguments that the HTML output of
>> is something people might want to control the look and feel of, more so
than specs as they are seen more frequently by customers.
>> Perhapes by default the styles are embedded in the html formatter but
>> a CSS stylesheet is passed to the formatter than it will suppress this
output and use your custom css.
>> something like:
>> ruby stories/all.rb --format html --css my_own.css
> That all sounds reasonable to me. Sensible defaults, yet configurable.
I like that idea. I haven't wanted to push back any of my changes to the
HTML formatter because I knew that Aslak's goal was to create a customer
facing editable HTML page.
However, for CI builds it is more useful as a programmer to not have that
functionality and inline the backtrace as well (which is something most
customer's wouldn't want to see.) I vote for inlining the basic styles
and providing the way to configure it as suggested above. I think the
HTML formatter should include the backtrace and then JS can be used to
hide it for a customer-facing version.
Which brings up the other question.. how do we want to handle the JS?
Due to how the HTML is written out JS is required to change the Story's
and Scenario's styles when a step fails or is pending. I did this with
lowpro for the rspec-story-tmbundle:
(The JS commented out in the file was the original JS that Aslak did for
the editable version.)
My JS is untested though (and only works for rspec 1.1.4), so I don't
know if you want to incorporate it into rspec, plus it would require the
additional lowpro.js lib.
The bigger question, I think, is how to handle the required JS files. I
don't think inlining the whole prototype lib is a good solution. So,
maybe we could default to generating full paths to the JS files which
reside in the rspec lib folder? Then we could allow options to be passed
in to modify the JS path, just like the CSS option above?
Any other suggestions/ideas of how to handle the external JS files?
More information about the rspec-users