[gnome-db] Re: Abiword report generator [was Re: Dynamic data queries]

[Dru <andru treshna com>]

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

I'd think of end of periods as offline but it comes down to how you've 
coded your app and its processors on which is workable. I've always done 
end of period reports as static, so i dont think i could develop a 
online dynamic report.  In my apps specify that you want run reports for 
this end of period then click on the reports you want and they are 
printed out/previewed etc.  I think treating them

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

I left most of the processing on the db server. And added only a few 
options for lcient side like searching, filtering, sorting etc.