RE: [gnome-db] Re: Multiple queries in report stuff
- From: "Santi Camps Taltavull" <santi camps terrassa org>
- To: "Vivien Malerba" <malerba gnome-db org>
- Cc: <gnome-db-list gnome org>
- Subject: RE: [gnome-db] Re: Multiple queries in report stuff
- Date: Wed, 22 Jan 2003 18:42:46 +0100
> >
> > > ..-> extend the DTD to store reports definition (queries and their
> > > relations, text, etc) and write the actual code which does the job of
> > > generating a report description which can be sent to libgda for
> > > "interpretation".
> > >
> > Referencing the DTD in libgda/report should be enought, I think. Also, to generate the report description, libgda-report will provide all the functions needed, so report is always interpreted and validated.
>
> It's more than that: in the mergeant file, we need to store all the
> informations which are used to generate the XML file for the report, not
> the report itself. If we only had the report itself (the report XML
> file), then we would not be able to present the user exactly the same
> GUI he had when he first created the report, and it would be more
> difficult to re-genetare the report if for example the queries changed.
>
I've been looking at mergeant DTD, and I continue thinking referencing the DTD in libgda/report should be enought. The DTD we have is not a DTD for the report itself, but for a complete report definition, so it should be able to generate exactly the same GUI from it. Take a look to the DTD in libgda/report, you will see that all report elements have attributes for x and y positions, and so on. Perphaps some new attributes could be necessary, like x and y positions for the queries, but it can be added. If I'm wrong, could you explain me what else is nedded, please ?
The idea is that the libgda-report framework will take the report definition from an .xml (or will create this xml throught its API), then it will execute the queries in the report definition and generate the report itself. I'm thinking in a generic "executer", with some abstract methods, and then N descendant plugins, one for each output format we want to support (xml, pdf, ps, rtf, ...).
Ah, one question, which format would be the best to be ower default output format? Initially I was thinking in xml, but perhaps it's easier to make a GUI for preview and print in any other format (using existing code and libraries). What do you think ?
> >
> > > I know this is quite a lot of work, but then we have something quite
> > > generic which uses the power of the Query object.
> > >
> > > Tell me what you think about this.
> > >
> > It sounds very nice. But I don't see how other elements of the report will be designed, like labels, lines, pictures, pageheaders or pagefooters, for instance. It will be another canvas where these elements are designed graphically, or how are you thinking to do this ?
>
> I feel quite confident we can make a nice GUI using a canvas and some
> widgets on it. Have a look at the DIA file I posted earlier, it is a
> basic preview of the canvas (without the report header, page header, etc
> we could add later). Tell me if you have some problems reading that DIA
> file (there are sometimes problems with fonts...)
>
Yes, I hadn't seen the .dia before becouse DIA was not installed on my job, but I've seen it now. If it's possible to define all the sections of the report, groupheaders, groupfooters, and so on, it's ok to me. It could be very nice to see.
Cheers
Santi
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]