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

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]