Re: [gnome-db] Papyrus, xml reporting

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2001-12-25 at 11:20, Andrew Hill wrote:
> > > Ok i've started coding but not much coding.  As in only got a small
> > > handful of C files and not even in CVS.  Been working on database
> stuff
> > > with nasty things like sql parses.  We are going for just postgresql
> > > direct support initially, just for ease of testing, and then we will
> put
> > > gnome-db and bonddb support in straight after we got layout sussed.
> > > anyway. xml file. I've attached it and it gives a good idea of what
> the
> > > end thing will look like.  Its slightly different to your xml.  
> > > 
> > 
> > I have seen the .xml file and I want to ask you if could you send us
> > patches for our DTD as modifications request to
> gnome-db-list gnome org,
> > I mean, with a few lines with a description of changes done.
> > 
> > Also, I want start to implement all this in HEAD branch (GNOME 2.0
> > version) so I need to work with you (and you with me) to do all as a
> > team work.
> 
> Anyway my team (myself, andre (lead), and liam as at the moment) are
> working on reporting system in our spare time.  We labeled it papyrus.
> If it should be called something else and you have a better suggestion
> let me know.  We want this reporting system to work with gnome-db though
> still have some backend independent.  
> 
perfect! From what I've seen in the code, I've had some ideas about the
backend independence. That is, in the XML file:

<group datasrc="gda:select * from foobar">

this will, obviously use the gda library to get the data. Then, we can
add more datasource kinds (postgres:, xml:, whatever:), and for this to
work great, we can have a plugin system (via CORBA interfaces) so that
you can easily add datasources to the report engine, having a set of
default ones.
Then, to get the data, we'll just use a GdaDataModel, which is an
abstract/database independent array of data. So, the report engine, when
getting its data, will parse the "datasrc" property from the group node,
and depending on the prefix (gda:, postgres:, xml:, etc), it will get
the data from one or the other datasource. That's the good thing of the
GdaDataModel's, that we can easily add new data sources to libgda.

A nice default datasource could be a xml: one, so that you can get data
from XML files generated by the gda-export utility, and thus run reports
without no database connections at all.

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

> libxml is used for rendering xml, langauges can be embedded into the xml
> but we are still fussing over python (has advantages for linking data
> but disadvanages with its tabbing), slang (its a bit messy) and guile
> (well its guile)..  
>
that is a very nice idea. We could just even support, later on, several
languages, by just using something like:

<language type="perl">
print "Perl";
...
</language>
 
> 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.
 
> I'm not worrying about the details of the xml files or the database
> intergration at moment as this is easy stuff.  At the moment i'm
> concentrating on getting the xml overall structure right and making sure
> we can correctly represent 99% of the reports we would write with it.
> The embedded langauge wont at the moment let you reorganise the way
> layout is provided, most of the time you wont need this as your using
> the langauge to work out what values are displayed where like calc
> totals.  
> 
yes, datasource stuff is very easy to add, as I said, even supporting
multiple datasources.

> what we arn't working on but would be good if we could have is a front
> end for generating reports.
> 
Jimspbox aol com is interested in working on this part, which, as I
said, should be the one using the GnomePrint preview stuff, as this is
the real UI thing.

> In regard to your DTD's your definations of xml tags will remain very
> similar, but the structure is different with the use of groups, group
> headers etc.  I prefer to leave DTD's till i get the thing generating a
> sample report, which it doesn't do at the moment. the state of the code
> is that it just parses the xml and greats the nessary layouts and prints
> lots of debugging info out.  it'll be another week or 2 at least before
> we have it generating simple reports.  though i have a forced deadline
> on this one for mid jan. aggrr.
> 
> regarding cvs.
> i'm running this from my cvs server at the moment but i'm fine with
> moving it tsover to the gnome cvs server but i dont have an account
> there.  also is there tools for mirroring cvs from servers cause that
> could be another option.  i got autoconf, autogen stuff etc already set
> up.  
> 
ok, so here are my plans. This is based on the idea that papyrus work is
going to be integrated directly in libgda/gnome-db CVS [1].

* currently in gda-report, there's only the framework for running the
reports through the report engine:

	string runDocument (in string xml);

this just gets the XML file, and fills in with data, and returns the
same XML with the data in it. For managing this XML file, I've started a
GdaReportDocument class, which will let programs easily manage the XML
format. We could just have a method on the GdaReportDocument class
(print) which generates the gnome-print format from the XML, but with no
libgnomeprintui use at all, to avoig GTK dependence

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

* 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

so, if this fits you, please have a look at how to integrate your
current code into the libgda/libgnomedb sources (CVS HEAD, for GNOME 2),
and tell us, so that we can start integrating it. If it does not fit you
(or somebody else), please add/remove/fix what I said.

If it fits you, I'll continue my work on the report engine (runDocument)
and add the stuff for the different data sources to be supported.

cheers

[1] send an email to accounts gnome org, cvsmaster gnome org and CC it
to me, and in the message just say that you're going to help us in
gnome-db, and that you want a CVS account
-- 
Rodrigo Moya <rodrigo gnome-db org> - <rodrigo ximian com>
http://www.gnome-db.org/ - http://www.ximian.com/