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
signature.asc
Description: Digital signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
