Rob Browning writes:
<snip>
> 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.
>
That's how I see it too.
> 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...
>
Absolutely correct, the way I read it.
> Thoughts?
* As you indicated, can mangle "report data" to do just about
anything you want, as it contains the logical information in the
report and nothing else.
* "report-data" representation will be unique to each report,
meaning any tool doing any mangling on it (for instance,
the structure generator) would have to be unique (or at least
substantially modified) for each report. Is this a problem?
* Internally, at least, we have to construct this kind of
logical information anyway (though we'd probably spit out the
document structure as we go rather than store it in its entirety)
In my view, if you wish to go with this extra complexity, that
all report generators should be constructed individually, with two
parts:
1) Report generator, which walks the accounts and generates our
"report-data". The "report-data" representation is unique
to this particular report (though, if we're feeling really
clever, we might specify some guidelines, or even a
meta-language, to construct this representation). This
information can then be saved to a file.
2) Structure generator, which walks the "report-data" representation
and converts to our "document structure" representation, which
would look something very like Christopher's proposal. This
document structure representation is standardised for all reports.
However, while we would use this structure for any reports we include
with the main Gnucash distribution, there should be no reason why
a user can't develop a report that goes directly from account-walking
to completed document structure.
This is a real "Swiss-army chainsaw" approach to reporting, but it
appears to be workable, and would give us the following very powerful
features:
1) We can export the logical content of reports without ANY
formatting information.
2) Reports can be targetted to any one of a number of output
formats (all that we need to do to adapt a report to a
specific output format is specify some page size, column width
and font information)
3) A new output target can be added without changing the reports
(again, though, you would need to specify font and a bit of
page layout information - no big deal).
Have I missed anything here?
--
---------------------------------------------------------------------------
Robert Merkel [EMAIL PROTECTED]
Humanity has advanced, when it has advanced, not because it has been sober,
responsible, and cautious, but because it has been playful, rebellious, and
immature.
-- Tom Robbins
---------------------------------------------------------------------------
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
