Scripting

[Gregory]

I have gotten around this by writing a set stored procedures for the 
mysql backend that more or less duplicate the data generated by the 
Scheme-based reports. Then I created Jasper iReport templates that use 
those stored procedures to fill their data sets. A small Java program 
automates the process of refreshing the reports and exports the results  
in PDF and HTML. I can run all my reports without ever having to open 
gnucash (except to add new transactions) and the end result is a single 
PDF document with all the combined reports including bookmarks to each 
individual report. It also creates an HTML version at the same time. You 
could easily also export Excel spreadsheets.

It works very well now, but took at least a month of tinkering and is 
succeptible to breakage from changes in the underlying db structure 
though this hasn't occurred yet. The configuration of a Java development 
environment for even writing the small Java program using only the 
neccessary Jasper libraries was very tedious. JasperReports makes really 
beautiful looking reports, especially the charts and is highly 
customizable so for me it was worth the effort.

You also have to make small changes to the structure of the accounts 
table in order to faciliate all the other SQL queries that calculate 
account balances, (store more hierarchial data) and some additional 
indexes need to be created to speed things up (price list, etc). I make 
a copy of the 'production' db into a 'reporting' db and then make the 
alterations there. A SQL script automates all of that, then the Java 
program runs refreshing the report file.


On 11/12/11 05:33, Andrew Ruthven wrote:
> Hi Hendrik,
>
> I've felt your pain.  The reasonably new python bindings are pretty
> helpful.  The documentation is still somewhat lacking, but there are
> some examples, and with a bit of digging through the doxygen output (and
> in some cases the .h and .c files) I've been able to work out how to do
> what want.
>
> Cheers!
>
> On Fri, 2011-11-11 at 20:40 +0000, Hendrik Boom wrote:
>> A few years ago I wanted some printouts of gnucash data formatted in a
>> form that my wife and I could use.  It was frustrating to me that the
>> easiest way to accomplish that was to reverse-engineer the gnucash file
>> and hand-coding a C++ program that read in the XML file and further
>> processed it.  The initial, usable, form of this program was written in C+
>> + in about a day.  Over the years, I've embellished it in various ways,
>> sometimes to change functionality, sometimes to accomodate subtle changes
>> in the gnucash file format.
>>
>> But it seems silly to duplicate stuff that's probably in gnucash itself,
>> and is even maintained by the gnucash implementers.  And it's obvious
>> that with the shift to a database, I should consider reading the database
>> instead of the (probably derivative and deprecated) XML file.
>>
>> I had looked at the gnucash source code, but I found it much harder to
>> understand than the XML file itself.  I had asked for information about
>> an API for understanding the internal gnucash state and was referred to
>> some (IIRC machine-generated) documentation.  It didn't help much
>> either.  In particular, it didn't make it clear what I had to do to set
>> up the internal gnucash state that it was reporting on.  While a fine API
>> for code that ws embedded within gnucash, it didn't really suffice for
>> external code.
>>
>> And looking at the guile interface for reports didn't help much  either,
>> even though I was an experienced Lisp/Scheme programmer.  At the time (is
>> this still the case?) the only usable documentation to the reporting
>> subsystem was the source code for the reports themselves.  This
>> definitely wasn't enough.  The report code was full of functions with
>> obscure names and equally obscure significance.
>>
>>    This isn't a problem with Scheme being a difficult language to learn.
>> It isn't difficult.  It can be learned by a competent programmer in a day
>> or two.  It's a problem with obscurity of the API the reporting subsystem
>> provides to the Scheme programmer.
>>
>> In subsequent years I've wanted to produce report output in forms other
>> than HTML, which, as far as I know, is the only one supported by gnucash.
>>
>> I've also wanted to write some custom data-entry software for getting
>> data into gnucash.
>>
>> Now presumably, given enough time, I'd have been able to overcome these
>> obstacles to interfacing with gnucash code the way it obviously wants to
>> be used.  But, of course, at the moments I was faced with the need to
>> produce, there wasn't enough time.
>>
>> ***
>>
>> Now I'm not really interested in just complaining.  If you'll forgive a
>> lurker, but long-time user, from speaking up, let me at least make a
>> proposal.  Yes, I know it will probably be a lot of work, and who will be
>> found to do it, etc.  What I'd like to hear is whether there are serious
>> flaws here, and whether it's ever likely to gain the social support to
>> make it worthwhile to try, etc.
>>
>> (1) The bulk of the code for gnucash should be a shared library, whose API
>> (s) provide all the essential functionality of gnucash.  This would
>> include code for starting up gnucash, shutting it down, reading gnucash
>> fies, opeining the usual gnucash window, and so forth.  The current work
>> of converting ad-hoc code to use Gobjects could go a long way to making
>> this API consistent.
>>
>> (2) The gnucash main program itself should operate entirely by using this
>> library's API.
>>
>> Maybe (1) and (2) is how gnucash is already structured; I don't know.
>>
>> (3) This library would be the basis for scripting interfaces to gnucash.
>> The API would make the gnucash library itself indifferent to the
>> scripting language being used.  Of course, the API must still be clearly
>> documented, or it will be practically useless.  Documentation in the
>> header files may suffice.
>>
>> ----
>>
>> It's worth noting here that some systems that can be used as scripting
>> languages are capable of handling the C and C++ interfacing on their own,
>> requiring no significant footprint in the gnucash library itself.  (I'm
>> thinking specifically  about Gambit C here, which is an implementation of
>> Scheme taht can compile to C.  No doubt there are others.)
>>
>> Other languages that different users might want to use on top of gnucash?
>> JavaScript, Python, Ruby and Erlang have been mentioned as languages that
>> are in the Lisp camp as far as semantics goes.  Several of them are
>> interpreted.  Google has recently put out a language that's designed for
>> programs that partly run on a server and partly on a browser.  Accessing
>> gnucash from a browser, even only read-only, could be useful.
>>
>> But now I'm getting far in advance of myself.  I'm currently arguing only
>> for a clear, conprehensive, documented API that others could use to build
>> their own edifices on top of gnucash.  That would open the gates to all
>> kinds of unexpected collaborations.
>>
>> -- hendrik
>>
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel