[Fuego] [PATCH 2/2] ftc: gen_report: Add new functions for getting data to, generate the report

Tim.Bird at sony.com Tim.Bird at sony.com
Fri Feb 23 04:49:54 UTC 2018

Just a few comments below.

> -----Original Message-----
> From: Hoang Van Tuyen
> Hi,
> On 2/22/2018 7:40 PM, Gustavo Sverzut Barbieri wrote:
> > On Thu, Feb 22, 2018 at 7:51 AM, Hoang Van Tuyen
> > <tuyen.hoangvan at toshiba-tsdv.com> wrote:
> >> Hello Tim,
> >>
> >> I am working on gen-report feature (support several other format like
> html,

These patches look good.  I skimmed over them, but didn't have
time to do a thorough review today.  Thanks for the contribution.
I hope to review them tomorrow, but I might not get to them until
next week due to other commitments tomorrow.

> >> pdf, ...).
> > do you plan to generate ReStructuredText (RST) and from there use
> > converters, or really generate the same result into multiple formats?
> >
> > using RST allows not only to generate multiple formats, but also to
> > customize output via templates, which is a nice addition.

> Thank you for your suggestion. I did not think about generating the RST
> format before.
> I will consider the method which generates the RST format, then use
> converters to generate
> other formats.

I think this might  be good, but a lot will depend on the implementation
and the context of the report.  I'm worried a bit that running it through
RST to get to html may take a long time (but I'm in the middle of adding my
own RST-based testcase documentation, that will have this same issue.)

Also, I haven't looked in detail at the types of reports we plan, but I'm worried
that the RST support for tables will require keeping track of column positions
for the column borders.  With plain ASCII, we haven't worried if something
breaks the column boundaries, as it's only intended for human consumption.
With RST, I think text exceeding column boundaries might break the 
parsing required for conversion to other formats.  This is something to watch
out for.

Also, so far, the generator has not dealt with column-spanning (like the
chart generator does in the results parser).  But long term that will be needed, IMHO.
This is going to be pretty complex in RST.  (I'm not sure if it's more or less
complex than doing column-spanning directly in HTML).

I would recommend doing the generator as a python class, with support
for different output formats as sub-classes.

Just my 2 cents.
 -- Tim 

More information about the Fuego mailing list