Easier reports with eguile-gnc

[Chris Dennis]

Andrew Sackville-West wrote:
> On Mon, Mar 23, 2009 at 09:14:00AM +0000, Chris Dennis wrote:
>> Andrew Sackville-West wrote:
>>> On Mon, Mar 09, 2009 at 09:34:16AM +0000, Chris Dennis wrote:
>>>> My previous posting on this topic[1] got no response, but I've now 
>>>> completed work on this project, and created an enhancement bug on 
>>>> Bugzilla[2].
>>> I might get some time to play with this a little this week, though
>>> it's still down the list for me. Have you attempted to save and
>>> retrieve a report generated using this? just curious how it went.
>> I hadn't, but now I have, and it seems fine.
> 
> cool.
> 
> So I've reviewed this a little bit and I have thoughts. 

Thanks Andrew.  Sorry for the slow response -- I've been busy and/or 
unwell for the past several days.
> 
> First, I think it's great work. I know Derek has wanted to see this
> implemented for a long time, and I think it's a great proof of concept
> (not that anyone doubted it, I think) of using eguile in this
> context. I'd like to play around with porting some more reports over
> to this to see how it plays out.

Any suggestions as to which report to convert next?
> 
> This is not criticism of the work you've done, but rather an attempt
> at discussing what to do with this work going forward. Note too, that
> I'm back in school and have almost no time to work on any of this, so
> consider this armchair development for the time being.

I'm quite open to constructive criticism.
> 
> First, I think it's a little kludgey using the existing options code
> with the new eguile template.

True, but it's there and it works.  And I don't know how to do it any 
other way.

> I don't like the use of two files to
> specify a single report, at least in this manner (more on that
> later). I don't know that there is a solution, just an observation.

I think the two-file approach is fairly fundamental to the design.  The 
template file is supposed to be mainly HTML -- how much Guile code is in 
there as well is up to the author -- see below.

It can have advantages too -- a single 'report.scm' file could process 
different 'report.eguile.scm' files in different circumstances (for 
different languages perhaps, or ... well, I can't think of a good 
example at the moment.)

One problem with the two-file system is in working out how to specify 
the name of the template file in an operating system-independent way. 
Any ideas?  In the end I just made it an option, so that specifying the 
right file is the user's problem!  i.e. it works on Linux if your userid 
happens to be 'chris'; if not, you need to tweak the 'Template file 
name' option.  I know in Linux it could evaluate '~' as $HOME, which 
would be a start, but I need advice on doing the equivalent on other 
operating systems.
> 
> Is it possible to enumerate the options in the beginning of the eguile
> template file directly? Bearing in mind that if all the reports were
> converted over to something like this, and if the intervening
> gnc-document step could be removed, then there would have to be some
> other way of load the reports on startup. And maybe this goes
> hand-in-hand with solving the long desired "specify options before
> instantiating report" improvements. (I really don't know how
> complicated that particular bit is, but I suspect it's not *too* bad)

Rewriting the options code is a job for someone who knows more about the 
internals of Gnucash that I do.
> 
> On the multi-file format, is it possible to remove all the extra logic
> from the beginning of the eguile file to the main scheme file? I'm
> thinking that the ideal situation would have all the necessary logic
> in the first file so that the eguile file merely has the html code
> with the calls to the functions in it. THat makes it *much* simpler
> for users to mess with the html as they like without having to be
> exposed to the guts of the calculations. And in that case, it
> definitely make more sense to have multiple files. One file is
> concerned with data and the other with presentation, a good thing I
> think.

Yes, most of the Guile code could be in the 'main' report file.

On the other hand, one side effect that I found very helpful when 
developing the tax invoice report was that changes in the template file 
can be seen instantly just by reloading the report, rather than having 
to restart Gnucash.
> 
> On the longer term front, if there were a sufficiently sophisticated
> library of functions to call on from within the template, maybe we
> could ultimately develop a better custom report generator that
> essentially incorporates a simple html editor with some process for
> plunking in pre-defined guile functions to get at the data. 

Yes, that would work for quite a lot of the code.  That library could be 
built up as required, as people come across useful and reusable chunks 
of code.  But there are plenty of instances (in my taxinvoice report at 
least) when conditional bits of HTML are wrapped up in Guile code in a 
way that would be difficult to unravel.  Unless we invent a new layer of 
abstraction that would effectively be a new markup language -- but I 
don't think that's a good idea.
> 
> So, now that I read back over this, it all seems pretty crazy, and I
> think I haven't read your code deeply enough to make really
> substantive comments. But I leave these ideas out there for
> consideration. 
> 
> Finally, I'm not really sure what should be done with this work of
> yours. I don't think it's ready for 2.4, and so should maybe go into a
> branch or just remain uncommitted until after 2.4 comes out. 

Could eguile.gnc itself go into trunk so that people can experiment with it?

> Then I
> think we need to make some real decisions about where reporting is
> going and how this work may or may not be a part of that longterm
> plan. I think that we have a pretty significant library of guile code
> already built and throwing it out would be a waste (though I know
> there is good reason to do so, including possibly abandoning guile
> altogether, as well as things like "clean slate"). But is really needs
> some restructuring and the framework I think needs some
> redesign. Certainly, culling through all the reports and pulling out
> and generalizing a lot of the functions would be beneficial for a
> number of reasons and would make your eguile template thing better (by
> eliminating some of the logic that is currently in the template).

Part of my motivation for doing this in the first place was that I found 
Guile to be such an ugly, counter-intuitive, unreadable language that I 
couldn't work with it creatively.  Having got into it though, I've found 
that I rather like Guile, and I can see why it was chosen.  But it is a 
steep learning curve for someone who just wants to modify a report -- 
hopefully having most of the layout of a report shown as HTML, even if 
it's tangled up with Guile code, will make life easier.

cheers

Chris
-- 
Chris Dennis                                  cgdennis at btinternet.com
Fordingbridge, Hampshire, UK