Re: GnomeDbReport

[Rodrigo Moya <rmoya tsai es>]

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

I would include the visual stuff in the GnomeDbReport widget. All the backend
stuff you may need could be in a separated library or as an independent project
if you don't want it to be gnome-db-dependant. The report widget should allow
modifications at run-time so that we can then write a report writer
application.

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

yes

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

yes

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

connections could be closed as soon as all data coming from them has been
fetched.

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

yes, this is very important. In fact, I've been myself doing reports (with
Prolifics Report Writer, which I don't recommend to use, although the idea of
how it is done is very similar to what you're saying, but it does not work!)
and I've been remaking some of them in order to include headers for each page,
because the customer wanted it.

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

The interface should be the same as for the rest of providers, so no matter
which backend is being used, as long as we respect the interface.

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

Instead of direct SQL statements, we should rather code the query in
XML (Vivien is working on this).

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

I agree with almost everything!

>
>         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 ?)
>

Well, for the gda-clnt XML interface there isn't a DTD, but I think that as
soon as we've got the format, making the DTD should be trivial (or not?)