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 cgden...@btinternet.com
Fordingbridge, Hampshire, UK
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
