Re: GnomeDbReport

[Vivien Malerba <malerba linuxave net>]

On jeu, 30 mar 2000, Cédric 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.
> 
>                      Cédric
> 
>  PS1 : Sorry for my terrible english, but my german is way worst.
>  PS2 : Cedric is very OK ;-).
> 

Cheers!

Vivien