Re: [gnome-db] Papyrus, xml reporting

[Andrew Hill <andru treshna com>]

On Thu, 2001-12-27 at 05:09, Will LaShell wrote:
> I'm not sure if this has been handled by the xml format, but it should
> at least be thought about. Two things that are paramount to essential
> for the automated reports we do here at OFS, are subreports, and the
> ability to pass a report arguments.

agreed. the last prototype before papyrus used arguments heavly. 
Another important thing is to have the entire reporting system command
line driven so its easy to use script to minulipate the overall reports.
 
> With subreports you basically have a report and then there is a
> reference to another report which will be embedded into this report.
> Typically we use this to include data from different datasources or to
> quickly include the contents of a secondary report into a "master"
> report. 

I'd see that to be handled by a special xml tag or in the langauge.
langauge easy to impleiment workaround.

> Being able to pass reports an argument is nice because you can
> manipulate your report sql depending on what something looks up. This
> may not make a lot of sense, but I'll be online today on #gnome-db irc
> if anyone wants to talk about it.
>
> Reporting ability would be incredibly nice to add to the features we
> have with gnome and gnome-db.
> 
> Now if gnome-db would just have python bindings I'd -really- be happy.

just write em. I know python-orbit arn't the nicest peice of code cause
he gave up on it halfway though but given some effort wouldn't be too
hard to get going.
 
> On Wed, 2001-12-26 at 03:22, Rodrigo Moya wrote:
> > On Wed, 2001-12-26 at 03:29, Andrew Hill wrote:
> > > > 
> > > > > gnome-print is used a lot for the actual printing, previewing etc.
> > > > > though we ran into a few minor short comings with it which wont take
> > > > > long to modify gnome-print to resolve these (like not been able to run
> > > > > reports non-interactively).
> > > > >
> > > > hm,, gnome-print should not be used (at least libgnomeprintui,
> > > > libgnomeprint would be ok) in the report engine, since this will make it
> > > > depend on GTK, which is not good.
> > > > The preview stuff should belong to the UI parts of the architecture
> > > > (libgnomedb)
> > > 
> > > libgnomeprint still depends on all the gnome stuff.  I know its bad been
> > > tied to UI libary like gnome-print but we looked at 4 different libaries
> > > and gnome-print was the most commonly installed feature rich one of them
> > > all and didn't have any annoying little bugs that screwed up stuff in
> > > the first prototype.  you could take the render_print.c and print.c into
> > > a different libary, though there are parts of the xml parser that
> > > currently use gnome, in regard to fonts etc.
> > > 
> > I was talking about GNOME 2's libgnomeprint, which is separated into
> > libgnomeprint and libgnomeprintui. The first one does not link with GTK
> > at all, so that one is ok to be used in the gda-report part (libgda does
> > not use GTK at all). I was saying that all libgnomeprintui use should be
> > moved to libgnomedb, where GTK is already used.
> > 
> > > > > postitioning is both relative and absolete.  relative been the first
> > > > > choice.  data is managed in groups, and groups can be sub sets of
> > > > > groups.  Report generation isn't single parse and the whole thing is
> > > > > generated in a 2d workspace before been dumped to gnome-print. This
> > > > > makes it resource hungry but it also gives us the best felixablity.
> > > > >
> > > > my idea, on the report engine part, is to just return the XML filled in
> > > > with data from the different data sources. Then, the rendering
> > > > (conversion to gnome-print for previewing and printing) should be done
> > > > on the client side, so I think it is not a big problem if it is resource
> > > > hungry, as this will be done on the client side.
> > > 
> > > arr ok now we differ.  I was using the XML to define the report, similar
> > > to how you would use HTML to define a web page. And then report server
> > > would read the xml and generate a report (ie a pdf file).  though the
> > > report system could only be client side effecivly.  The xml was not
> > > going to have invidiual row data in it but this would be handled in
> > > memory with structures.  though this is one differing approach to xml.
> > > i'll ask andre about it.  
> > >   
> > yes, we could just modify the runDocument method to be:
> > 
> > Bonobo::Stream runDocument (
> > 	in Bonobo::Stream xml,
> > 	in string mime_type);
> > 
> > and have the engine itself make the conversion if the client asked so.
> > 
> > >  
> > > > * XML format: I don't really care about the XML format we're going to
> > > > use as long as it fits all our needs. So please, Carlos and Andrew, just
> > > > get along on the format you both want.
> > > > 
> > > > * datasource independence: as I said, I can easily add a CORBA interface
> > > > for adding new datasources to the report engine, and a C wrapper for it
> > > > in libgda-report. This, as said before, will work by using a prefix
> > > > (gda:, xml:, etc) in the command to be executed. I'd prefer to use CORBA
> > > > interfaces for this rather than normal plugins (.so), since it makes
> > > > more sense to use the glue used everywhere in libgda.
> > > 
> > > just put the corba interfaces in the binding libary, there is no
> > > bindings for corba i know of for talking directly with postgresql.  This
> > > is just to give more flexibility for porting (orbit doesn't currently
> > > work under win32), and future proofing. and hey the works already done. 
> > > plus i need this reporting system to talk to some oldschool databases of
> > > mine which dont have corba bindings.
> > >  
> > there's no need for CORBA bindings for each datasource. We will provide
> > them. That is, I've coded a GdaReportDatasource class, which implements
> > the Datasource interface I talk about. And, to add a new datasource,
> > you'll just have to:
> > 
> > ds = gda_report_datasource_new (GdaReportDatasourceGetFunc func);
> > 
> > in get_func, you'll just get a command string, and you'll have to return
> > a GdaServerRecodrset, which you create with gda_server_recordset_new.
> > 
> > That is, what we would do for adding datasources is just create new
> > GdaReportDatasource objects.
> > 
> > If you want to port to win32, for instance, you just have to modify the
> > CORBA bits, but you can keep the same API than on UNIX/Linux
> > 
> > > > * UI: this is the part that would use the preview stuff from
> > > > libgnomeprintui. Also, we need a designer, which is on what Jim will be
> > > > working on. This should be in libgnomedb
> > > 
> > > At the moment payprus covers both the UI and the low level stuff.  I can
> > > make sure they stay reasonbly seperate.  but as i said before the
> > > wouldbe outputed xml file is stored in memorory at the moemnt in data
> > > structures. the phases it goes though in report generation are as
> > > follows:
> > > 
> > > parse xml, generate strcutres reprensenting it.  connect to db's etc.
> > > generate a layout, defining hwo the objecst correspond to each other
> > > get the data, create a render object.
> > > <- here a step could be added to generate an xml file from the render.
> > > (this would be taking the render_item structure present and creating an
> > > xml file from it, and then a function to re-generate the structure
> > > again)
> > > render_print lays the stuff out in 2d space.
> > > print sends the stuff to libgnomeprint
> > > 
> > ok, sounds nice. I'll continue looking at it today, and see how all this
> > can be mixed keeping all people happy :-)
> > 
> > cheers
> > -- 
> > Rodrigo Moya <rodrigo gnome-db org> - <rodrigo ximian com>
> > http://www.gnome-db.org/ - http://www.ximian.com/
> > _______________________________________________
> > gnome-db-list mailing list
> > gnome-db-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-db-list
>