> 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 current html formatter in trunk no longer requires js to apply styles for failure or pending. So that moves us along to looking at js to hide/show the backtrace. The idea of showing the backtrace in the html has been something I've been debating for a while. I did come to conclusion that as a developer I have the build log (or terminal stories are run from) as a source for story errors. Hence I felt I was best left leaving my stories clean for the non-developer users of the stories. I can see from your post that there is a usecase for a more developer centric output. My goal with the default story output was to get a standalone .html file which can then be moved around and played with without having to worry about managing css & js files. Pretty much just as the spec reporter does. Thinking about a developer centric report and maintaining a standalone html report starts to make me think about different formatters/reports. * Default standalone * Custom css -- * Developer centric story report - js & customizable css So this move us to something like: *ruby stories/all.rb --format html *ruby stories/all.rb --format html --css my_own.css AND *ruby stories/all.rb --format developer-html I think the first two are important and represent the majority of use cases. If we can separate the idea of js and backtrace output to a separate formatter then we can start work on the first two outputs now (and make story reports usable out of the box). Then we can use a developer formatter as a sounding board for advanced/verbose output (profiling each story aswell perhaps?). Potentially Aslak's new interface could move to this dev-formatter(or some other formatter) so that we continue development without disturbing those using the simple default output. What do people think? -- Joseph Wilk http://www.joesniff.co.uk Ben Mabey wrote: > David Chelimsky wrote: >> On Fri, Jul 25, 2008 at 8:08 AM, Joseph Wilk <[EMAIL PROTECTED]> > wrote: >> >>> 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 > does. >>> 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 > stories >>> 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 > if >>> 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. > Other opinions? >> > > 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: > http://github.com/bmabey/rspec-story-tmbundle/tree/master/Support/resource/rspec.js > (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? > > -Ben -- Posted via http://www.ruby-forum.com/. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
