From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Sony.onmicrosoft.com; s=selector1-Sony-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J3SgdgOMTH5NexL/XlWdZpvxJ9ljht9gk4rfhsBT5HQ=; b=bSwxNnvsG/gRi42m+GEMF3I4G2FcWsBwWkpK5VMd+Q3iFHcERzHuyHbGSCCL7XzRJ80hDT8Mn0WUbuP2hwJV1LKxDmxYgzgf+TeJ2vGKO322EFgAqwZn88fbuGF6REMIPe4BGCK8i4jfgd3dBwJQNa9A0a7QG44VC0ikLZJgZos= From: Date: Fri, 23 Feb 2018 04:49:54 +0000 Message-ID: References: <48ee9177-bd98-d609-5328-b21a6f110e1e@toshiba-tsdv.com> <49616ddb-9c5f-8351-9610-a4d54abd1d48@toshiba-tsdv.com> In-Reply-To: <49616ddb-9c5f-8351-9610-a4d54abd1d48@toshiba-tsdv.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fuego] [PATCH 2/2] ftc: gen_report: Add new functions for getting data to, generate the report List-Id: Mailing list for the Fuego test framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: tuyen.hoangvan@toshiba-tsdv.com, barbieri@profusion.mobi Cc: fuego@lists.linuxfoundation.org Just a few comments below. > -----Original Message----- > From: Hoang Van Tuyen > Hi, >=20 > On 2/22/2018 7:40 PM, Gustavo Sverzut Barbieri wrote: > > On Thu, Feb 22, 2018 at 7:51 AM, Hoang Van Tuyen > > 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 w= orried that the RST support for tables will require keeping track of column positi= ons 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=20 parsing required for conversion to other formats. This is something to wat= ch 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 ne= eded, IMHO. This is going to be pretty complex in RST. (I'm not sure if it's more or l= ess 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=20