Reporting system and potentially Python

Geert Janssens janssens-geert at
Fri Jul 8 05:21:13 EDT 2011

On vrijdag 8 juli 2011, Tim M wrote:
> What I'm looking for is this:
> Separate the act of actually gathering the data from the GnuCash database
> from transforming it for display, so that the output can be made much more
> interactive and easy to style and make 'pretty' :).  Use a well known
> programming language to aggregate the data to make it easier to create new
> reports which output different sets of data.
> I've thought about this a little bit, and here is what I am thinking.  Let
> me know if this sounds un/reasonable or just plain incorrect.  (Note that I
> am basing this off of not being familiar yet with how the current scheme
> architecture actually manages pulling the data out of gnucash, so please
> correct me where I am wrong or point out the significant flaws)
> 1. Create the 'new' reporting system alongside the existing one so that the
> reports do not suffer until the existing functionality can be fully
> replaced by the new system.  After all reports are replaced and working,
> the old scheme code could be pulled.
> 2. Create a set of libraries and/or use the existing gnucash libraries for
> querying information from the database.  Based on the discussion, I presume
> C or Objective C would be best and just avoid Python/Scheme altogether (I
> am not sure how the scheme system actually performs the data queries right
> now).  If all the necessary code is already in place, then this does not
> require any work.
> 3. Using these libraries, create the code for aggregating the data (also in
> C or Objective C) for each report.  A single prototype report would be OK
> to start.  Output the report data as structured XML.  The XML data should
> adhere to an XML schema.
> 4. For each report, create an XSLT file which will transform the data into
> HTML/XHTML for display.
> 5. A small amount of javascript would be needed to perform the actual XSLT
> transformation but it would be pretty small.
> 6. Style the page elements using CSS.  Also, I think the jqplot patch that
> has been made could be migrated in to the new reporting system, as those
> graphs look really nice.
> I think there are several benefits to this approach:
> 1. Currently reports can only be exported as HTML.  By making the reporting
> code export an XML data structure, reports could be easily exported from
> GnuCash as XML (pre-transformation) or as HTML (post-transformation).
> 2. Anyone could write their own XSLT transformation file to display the
> data differently.
Like pdf, using the fop transformer. An improvement that would also be greatly 
appreciated by users of the business features.
We have already some experience with this transform in the gnucash-docs, so it 
would not be too difficult to apply that experience on the reports.

So me too I like your ideas of starting with xml and the separation into XSLT, 
CSS and friends.

> 3. The actual XSLT, HTML, and CSS code would be very easy to read and
> modify by anyone familiar with it.  The backend reports would still be in
> C/Objective C for compiling the data and as such require some coding
> knowledge, but it would be much easier to start using than the existing
> scheme code.
This part is not clear to me. Do you mean that if Joe user wants to add a new 
report, he will have to write some C code, like for example to add a new data 
query ?

I guess that would limit the extendability of the reports equally to having 
them in scheme.

John's suggestion to find something sql-query like to gather data might be 
nicer, as would Yawar's proposal to go for a completely declarative report. 
Both mechanisms work generically with the raw data and would adapt easily to 
data format changes. By the way, GnuCash comes with a query framework for its 
data: qof-query. It mayor may not be suitable as a basis for the first 

I'm tempted to say here that such a generic and easy to use interface could be 
implemented as a later improvement, but at the same time I have a feeling that 
such a decision should be taken early on, because it would greatly influence 
how everything gets implemented.

> 4. The XSLT and CSS could be very easily modified and applied not only
> inside of GnuCash, but a user could also take the XSLT and CSS scripts,
> modify and apply them to the exported XML reports to give it their own look
> without touching the GnuCash code base at all.  For example they might want
> to style a report with a company logo or different colors or other
> graphical elements.
> 5a. In the future, it would be possible to provide multiple different XSLT
> and/or CSS styles for the reports so users could select the appearance of
> the reports. (If someone writes additional styles)
> 5b. In the future, it would be possible to allow users to import their own
> style sheets into GnuCash and apply them to the reports. (if someone writes
> the code to manage the import and style selection)
I already some kind of a theme foundry as part of the GnuCash website, where 
users can add stylesheets for others to use. Something in the lines of the 
online kde/gnome theme stores


More information about the gnucash-devel mailing list