Abiword report generator [was Re: Dynamic data queries]

[Linas Vepstas]

On Sun, Mar 07, 2004 at 09:21:49PM +1300, Dru was heard to remark:
> 
> >>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.

Yes, I agree, but no.  That's why I picked the bugzilla example.
At one end of the spectrum, you are right.  But there is a spectrum;
there is a whole range.  I was trying to empahsize that a form not 
only collects input, but it also displays output.  

To generate the data that one needs to display in a form, one might
need to run arbitrary complex queries.  For example, I've been trying
to develop a druid do assist users w/ accouting periods.  There is
a frightful amount of computation that takes place between the 
different panels in the druid.  I don't see the point of taking
that computation, the combing and sorting and refining huge chunks of
data, and making it into something static, some batch job that runs 
overnight.  Making that 'report' into something 'static'
doesn't simplify anything, it just makes things more complex.

If you wish, we can come up with two different words e.g.
"online reports" and "offline reports".  As stated in the 
abiword/gnumeric thread, I have no love for "offline reports"
preciselu because they are not interactive, they are not dynamic.
And, in the meanwhile, I *still* have to write code to generate
user GUI's like the bugzilla bug edit page, which is a kind
of report. 

> 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.

Yes, be where did the data to populate that user interface come from?
That data may be from a complex SQL query, followed by a whole lotta
post-processing. The hard part is to prepare the data.  I don't want
to make the artifical distinction that my output device is a glade
panel as opposed to html or xml or an abiword document.  I want
to have the infrastructure to direct the output at a number of 
different output devices. 

--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933