GnomeDbReport

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

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

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


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