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

[Rodrigo Moya <rodrigo gnome-db org>]

On Thu, 2003-01-23 at 14:01, Daniel Morgan wrote:
> I have to agree with Rodrigo, I like the idea that the output of the report
> be XML. This way, any  plug-in could be made to transform it to something
> else, such as,
> - print to printer via postscript or gnome-print
> - HTML via a XSLT provided by the user
> - HTML using the GNOME-DB Reporting software's defaults
> - PDF (Adobe Acrobat)
> - RTF - Rich Text Format
> - GNOME Office Documents, such as, Abiword or Gnumeric
> - etc...
> 
yes, exactly. I think the XML->something conversion should be done on
another level, not by the reporting basic engine. Of course, this will
be all available in the libgda API, but the converters would be just
external plugins.

> Also, the GNOME-DB Reports don't have to be used for just Reports, but
> templates for Letters or other type of documents which must be dynamically
> generated.
> 
yes. In fact, I was thinking on a 'Print grid' feature that would use
the reportig stuff to print it out. It would just have to generate the
XML and pass it over to the report engine.

> I would like to make a suggestion that the "database" functionality in the
> Reporting engine be optional.  There can be multiple sources of data, such
> as, XML, CSV files, or Gnumeric spreadsheets.  And another source of data
> could come from the user application that starts the reporting process via
> the GDA report API.
>
that was talked a long time ago, when we started thinking about the
reporting stuff, and it did nothing but stop the development at that
time. Of course, it is a very nice feature to have, but since we have
already a good abstraction via the GdaDataModel stuff, I think we should
be using that.

That is, we could have a 'get_model' callback (to be provided by report
client apps) in the report sections that made a call to a callback that
returns a GdaDataModel, which can be created as best fit (from data in a
gnumeric spreadsheet, etc).

That would make the reporting engine totally independent of a data
source.

>  Once the reporting process has started, the reporting
> engine can fire off events (signals or callbacks?) and the user application
> responds to them by filling in the blanks and sending the resulting data to
> the reporting engine.
>
this is a nice idea.

>   I don't know how this could be done; however, for
> complex reports, much of the logic for a given report should be in a user
> application.  This may even include the SQL too.
> 
well, this is a very nice feature, although I would leave it for
post-1.0, since this will mean that we have to add support for scripting
and all, which seems a bit overwhelming for 1.0.

cheers