Reporting system and potentially Python

[Hendrik Boom]

On Thu, 07 Jul 2011 20:48:27 -0500, Tim M wrote:

> What I'm looking for is this:
> 
> 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.

As far as I've been able to figure out so far, the python and scheme 
bindings use the existing gnucash libraries to access the data base.  So 
if the current reports are what you need, why rewrite in C?  But it does 
make sense to allow the Scheme reporting system to generate XML.

And if it's essential for some reason to have them compiled, the Gambit C 
implementation of Scheme (as in Debian package gambc) is capable of 
compiling Scheme into (rather unreadable) C.  Of course there are subtle 
differences between Gambit and guile, and including another tool into 
gnucash would be a big step.

> 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.

All in favour of allowing reports to be in XML.  It probably won't take 
too much effort to allow this.

It's what I'm already doing with my personal reporting tool that reads 
the gnucash XML file.  It's written  in C++ and has to be changed every 
year or so to adapt to changes in teh gnucash file.  All I needed for 
neat output was a .css file.  It's quite effective.

> 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.

If we're brainstorming about report-describing formalisms, has anyone 
looked at RPG, a commercial workhorse from back in the 1960's?  It 
wouldn't be directly applicable unless it's changed drastically since 
then, but some of its ideas may be.

> 
> 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).

Much desired.  But could probably be achieved with only minor changes in 
the present system.

 6. No reliance
> on Scheme or Python. Minimal Javascript, but that should be handled
> easily by webkit.

To achieve advantage 6 would require major changes, though.

-- hendrik