Abiword report generator [was Re: Dynamic data queries]
Dru
andru at treshna.com
Sun Mar 7 02:21:49 CST 2004
>>maybe sharing same reporting engine will also
>>help all the projects along.
>
>
> I'm concerned about the idea that the report generator is somehow
> an off-line batch processor. Take a look at the gnomedb report
> generator: it creates XML, good lord! With header and footer and
> colors! I'm sorry, but that is sooo wrong.
>
> Reports need to be thought of as the other half of forms. A "form"
> is a document where the use is queried for info. For example,
> the google home page is a "form". A "report" is how data returned
> from the database is presented to the user. For example, the
> result of a google search is a "report".
>
> Sometimes, "reports" are visually merged with "forms". For example,
> suppose you search for bugzilla bug 123. You see a "report" of bug
> 123, but that "report" is also a "form" which allows you to make
> modifications to bug 123.
>
> My point being that you could never build something like bugzilla
> from the the gnomedb report generator (and if I'm wrong, then
> I grossly misunderstand the gnomedb reports). The output of
> a report generator must be targeted to the same interface as
> the forms designer. In the case of dwi (and bond), this target
> is the glade widgets, although I argue here that it should also
> be a live AbiWord document. A report that is a static
> post-processed Abiword document is useless.
>
There is one major difference between forms and reports. Forms are
dynamic, reports are static. A form should have abilities to display
data, in a way a report with its widgets but this not a report. A report
is something that is going to be database intense, and you do it only
once a week or whatever. Ie you want a report of all bugs reported,
fixed and currently open this week. This is different from the show bugs
screen which lists all bugs that are currently open, or showing the
contents of a bug. Reports are run daily/weekly/month/yearly and you
want them as a pdf so you can save them and print them off and file them
away.
Forms and reports should be different entities, i'm against building
reports ontop of a dynamic envoriment just complicates things.
Anyway coming back to the gui, the gui must have the ability to show
dynamic report type data, like details of a bug, last 10 bugs reports,
most common bugs etc. These are reports but components of the user
interface.
More information about the gnucash-devel
mailing list