Easier reports with eguile-gnc

[Andrew Sackville-West]

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. 

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.

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.

First, I think it's a little kludgey using the existing options code
with the new eguile template. 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.

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)

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.

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. 

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

okay, enough rambling. 

A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20090331/ea3ac11c/attachment.bin>