Re: Abiword report generator [was Re: Dynamic data queries]

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]