Christopher Browne <[EMAIL PROTECTED]> writes:
> The alternative is to create a language that is "completely
> platonic" in being totally unaware at all times what the output form
> will be. That would mean we have to then create a separate
> translator, and effectively add a further sorta-language to the mix.
> I think it rather preferable to keep it pretty simple, having the
> operators inside be device-independent.
After reading the stuff you've been writing and thinking about it
more, I realized that I was arguing for exactly what you describe. I
was only thinking at the step of going from your account group to a
representation of just the data that should go in a particular type of
report. For example:
(report 'expenses-top-summary 2)
...
("Food" 300.0)
("Fuel" 50.0)
("Rent" 500.0)
This file could then be used to generate a line-item report, or a
graph.
However, you're right, with this setup if we didn't want to have to
add a new rendering backend for each output format every time we
wanted to create a new report, we'd have to develop another
"sorta-language" which specified "document structure". So generatng a
report would be:
account-group -> report-data -> document-structure -> rendered-document
And the document-structure representation would look like the stuff
you've been describing.
Of course, the drawback to the method you suggest (I think, and
correct me if I'm wrong), is that it's less geared toward those people
who want to store their "report data" in a way that lets them mangle
it as they please. Though perhaps that should be thought of as a
separate issue, not synonymous with reporting...
Thoughts?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
