Hi Vikash and Leo (thank you for joining us, btw),
Well, I'm open to suggestions on how to design the Report API, but here's how I imagine it at the moment:
It believe it would be nice if we had a full representation of a Report in the form of plain-old Java objects (the getReport method would return this instead of a String). Reports would be composed of some attributes like the report's title and a list of the "report components". By "report components" I mean the charts, tables and text sections that are present in the report.
To understand better what I mean, let's take a look at the Modularity statistic (run it and take a look at its report before continuing, if you haven't already). On that report, the report's title is obviously "Modularity Report", the report components would be a "table" for showing the Parameters, another "table" for showing the Results, a chart of "Size Distribution" and two text sections for the references for the algorithm and the resolution. The code for building this report would look something like this:
Code: Select all
/* Warning: this is just for explanation purposes, the methods and classes' names would obviously be different and should follow the Gephi's guidelines for implementing new features (see the tutorial I linked in my first post of this topic) */
public Report getReport() {
Report modularityReport = new Report("Modularity Report");
ReportTable parametersTable = new ReportTable();
parametersTable.setData(...); // insert data into the table somehow
modularityReport.appendComponent(parametersTable);
// ... create and add the other components to the report ...
return modularityReport;
}
I believe this is a good way because it simplifies the report building process and abstracts the layout of the report from the content/data. If someone is implementing a new statistic/metric on Gephi, he/she would only have to know how to use the Report API to build the report. Besides, by abstracting the content from the layout, all the reports would have a familiar look (this is where the template goes in).
I think this would solve the problem of constructing the reports. To render/print the report into the JavaFX browser, we would have some sort of "report printer" that would build the HTML source (and pretty much everything else like any necessary JSON objects, dynamic Javascript code, etc) based on the report object. I am okay with the idea of appending the charts' data into the HTML template like Leo suggested.
The idea of having a HTML template is just to make sure all the reports have the same layout. I'm not sure which is the best library to do this in this case. I suggested StringTemplate on the wiki because it's simple and it looks like it would do the job (honestly I have never used it, you're free to suggest a different approach).
Hope this helps to answer your questions and gives you something to think of. Again, this is just my two cents and NOT a specification of how the Reports API should work. Feel free to share your thoughts and even suggest a whole new approach!