RE: GnomeDbReport

["Cédric PINEAU" <cedric pineau dree org>]

	It took me a moment to understand it well.

	Now, it seems that we could separate my XML report file in two :
		- XML representation of the requests (Is your attention limited to SQL
statements or will it be extended then to LDAP and so...)
		- Presentation information for the report.

	So, yes why not working together on the XML DTD for SQL statements, then
you'll write the library for getting/saving such statements and I will do my
own library for getting/saving whole reports, ie using yours for SQL, and
some other code for the XML presentation file. (I think it's not a good to
have both in the same library because your code would be more general
purpose, no ? Your primary goal is something else, that does not need report
presentation loading facilities... Tell me if I'm wrong)

	Cédric.


-----Message d'origine-----
De: Vivien Malerba [mailto:malerba@linuxave.net]
Date: jeudi 30 mars 2000 10:28
À: cedric.pineau@dree.org
Cc: GDA Mailing List
Objet: Re: GnomeDbReport


On jeu, 30 mar 2000, Cedric PINEAU wrote:
> GnomeDbReport
>
>
>   As it seems that there are others people interested in working on that
> project, here is a description of how I see the things.
>
>   My primary goal is to provide a report generator for Gnomedb, similar to
> ReportSmith or QuickReport for Delphi, in order to port a commercial
> application I wrote to the Gnome plateform.
>
>   The basic ideas I have formulated so far have met Rodrigo's owns, so I
> think that they can be adopted :
>     - We have to develop an app, whose purpose would be to create reports
>     files. Thoses files would then be loaded and processed by any apps,
> using
>     a linked library that will be part of gda-clnt-ui.

Would it be possible rather to develop just a bonobo component to do that
task
(create report files), so any app using gnome-db is able to generate its own
reports by incorporating this component. What do you think?

>     - The reports are stored as XML files. It includes both databases
>     informations and SQL statements, and presentation (positions of
> fields...)

I'm working now on creating a lib to desing queries in a generic (XML) form,
that is independent of any SQL (or whatever) language. The queries done in
this
way will be SELECT, INSERT, etc (classical ops in a db) and also queries to
store and retreive the database structure (tables, sequences, functions,
data
types,...). We could merge our efforts and create a unique lib which has all
the above mentionned features and the possibility to store reports.

>     - Printing is done using the Gnome-print library, which provides
preview
>     facilities (on a canvas) and can generate postscript files (and of
> course
>     print directly as well)
>
>   Here are other ideas that are based on the report generators I know,
with
>   some sorts of improvements :
>   (And that are highly debatable, if I am in a good mood ;-)
>
>     - A report has a set of requests to possibly different databases.
>     - A report has a set of ordered bands
>     - A band can have a master field. In that case a printing of the band
>     occur each time the value of the field of the given request change.
>     - A band can have sub-bands that are bands.
>     - A band can have a footer band that is printed after all the
sub-bands
>     have been printed, and for each occurence of the given band.
>     (Usually used to print summaries of the sub-bands for that band)
>     - A band can contain requests, whose parameters can be results of
global
>     or parents bands requests
>     - Of course, master fields that drive the bands printing should belong
> to
>     global or parents bands requests too.
>     - A band has a background, a height, frames ...
>     - A band has a set of fields
>     - A field has a background, dimensions, framesand contain an
expression
>     - An expression is a string that is evaluated at rendering time, that
> can
>     reference fields of locals, parents or global requests.
>
>   The process of such a structure will follow this algorithm :
>     Open connections and do global requests.
> (1) Print bands in order, that is for each band :
> (2)   Open connections and do local band requests if any
>       Print the band and its fields
>       if band has sub-bands, print them recursively on (1) to (3)
>       if band has footer band, print it
>       if band has a master field, and if it remain lines in the given
> request
>       do 'next' on it and go (2)
>     (end for)
> (3) Close all connections (Surely this could be optimized)
>
>   Special considerations could also be taken for presentation, such as
> allowing page header and footer bands, column headers and footers (allow
> to reprint the columns names on the beginning of each page, regardless of
> the size of the page : computed at rendering time)
>
>   Again, this system fits my need, but there may be better ones. Feel free
> to propose something else.
>
>   Some parts of the problem are still not clear at all for me at the
moment
>:
>     - How can we integrate reports on XML or LDAP data sources ? I haven't
>     looked yet at the proposed interfaces for those sources in the GDA
>     library.
>     - Do we need a basic language for operations on the requets' results ?
>     - Is it better to separate SQL statements from their presentation ?
> Maybe
>     we could code the presentation information in an XSL file.
>
>   So far, I've been looking at the XML library (libxml) and gda_clnt.
>   Here are some of the information that should appear in our XML report
file
>:
>
>         Report :        Author
>                         Paper type
>                         Margins (North, South, East, West)
>                         Background
>                         Frames (North, South, East, West)
>                         List of requests and bands (I don't know if it's
> best
>                         to rely on an XML hierarchy for sub-bands and
local
>                         requests, or to use links between elements in a
flat
>                         file)
>
>         Request :       DSN
>                         User
>                         Password        (not to fine, but ...)
>                         SQL statement

Or XML representation of that SQL statement.

>
>         Band :          Background
>                         Frames (North, South, East, West)
>                         Master Field if any (it's an expression to
evaluate)
>                         Height
>                         List of local requests, fields and sub-bands
>
>         Field :         Position (x, y, width, height)
>                         Expression to evaluate and print
>                         Background
>                         Frames (North, South, East, West)
>
>         Expression :    String to evaluate
>                         Police
>                         Color
>                         Size
>                         Style (Bold, ...)
>         ...
>         and lot of other informations that we'll add on time.
>
>
>  Well, that's approximately what I've been thinking about so far.
>
>
> 	TODO :
> 	Depends on what you feel confortable with, but as a whole :
> 	- Make things clearer. We'll have to discuss all that.
> 	- Set an XML format (Do you know DTDs ?)

See my proposition to work together on this.

>
>
>  I'm waiting for your comments Karl.
>
>                      Cedric
>
>  PS1 : Sorry for my terrible english, but my german is way worst.
>  PS2 : Cedric is very OK ;-).
>

Cheers!

Vivien