Re: Abiword report generator [was Re: Dynamic data queries]
- From: Dru <andru treshna com>
- To: Linas Vepstas <linas linas org>
- Cc: Andrew Hill <dru treshna com>, Charles Goodwin <charlie xwt org>, gnome-db-list gnome org, gnome-office-list gnome org, gnucash-devel gnucash org, Tim Lord <timl treshna com>
- Subject: Re: Abiword report generator [was Re: Dynamic data queries]
- Date: Sun, 07 Mar 2004 21:21:49 +1300
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]