RE: [gnome-db] Re: Multiple queries in report stuff



Have you looked at the DTD for dbreport for ideas?

http://www.comm.cc/~gianx/dbreport/README-XML.html

-----Original Message-----
From: gnome-db-list-admin gnome org
[mailto:gnome-db-list-admin gnome org]On Behalf Of Santi Camps Taltavull
Sent: Wednesday, January 22, 2003 12:43 PM
To: Vivien Malerba
Cc: gnome-db-list gnome org
Subject: RE: [gnome-db] Re: Multiple queries in report stuff


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



_______________________________________________
gnome-db-list mailing list
gnome-db-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-db-list




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