"Rob Coker" <[EMAIL PROTECTED]> writes:
> While I've put my $0.02 on everything else, I'll add that I'd really
> like to see the native format of reports to be text (preferably
> comma delimited). One could site all the unix-philosophy reasons
> for doing it this way, but the bottom line for me is that I can then
> use any spreadsheet to format it however I want.
Hmm, I'm not sure what you mean by the "native report format". When a
report is generated, it's just spit out as html. Generating
comma-delimited data would be a separate (though similar) process. If
you're arguing that we should go through an intermediate comma
separated format on the way to html, that might be feasible, but I'm
not sure it wouldn't just make more sense to just structure things so
that report generation involves invoking callbacks to do the
formatting while traversing the data. Then you can drop in callbacks
that either do comma-delimited or html output.
This has the advantage of being almost exactly how I've implemented
the scheme replacement for eperl. An alternate, but roughly
equivalent approach would be to generate the data for a given report
in scheme (as lists or whatever's appropriate), and then pass this to
"formatter" functions (for html, CSV, etc.). Right off the top of my
head, I'm not sure I see how this would be any better, and it has the
potential to require more memory on average.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
