[Fwd: Re: re[4]: [Rlib-users] new test release soon]

[Bob D. <bd...@si...>]

Err.. forgot to send it to the list

On Wed, 2003-11-05 at 10:55, John Buckman wrote:
> > John you are my hero!!!!
> > You saved me a whole hell of a lot of time
> > This now works... and I assume the bindings will be just as easy in
> > other languages :)
> 
> Yes, because your normal api is a very thin shim on top of your C api, all the languages will work the same way, with exactly the same api. Makes documenting really easy too.

Yea.. the language api should be as simple as possible... and all the
logic be in the report xml.. that we it is extreamly portable

> 
> I see that you added rlib_set_output_format_from_text() so as to get rid of the ENUM -- that's the right way to do it.

We have both now

> 
> This isn't a big deal, but if you added two bools to the struct ("test" below) you hold, with
> 
> bool has_initialized;
> bool has_executed;
> 
> then when rlib_add_datasource_mysql() is called, rlib_init(); could be called automatically, and the same thing with spool() calling execute().


Well.. not exactly because rlib_add_datasource_mysql needs a pointer to
a rlib.. and returns errors now....

same argument for the other 2

> 
> Can one re-use a report object, or must it be freed after use? If it has to be freed, then you might as well make spool() call free().

Well.. I'm adding 2 new functions to rlib right now 

char * rlib_get_output(rlib)
int rlib_get_output_length(rlib)

these will give you direct access to the report after executon.. this
way you can save them to a file and stuff

> 
> Another easy feature, that'd be convenient, and make your api cleaner, would be a short-form call that does it all, namely:
> 
> rlib_mysql_report("localhost", "user", "password", "database", "select * from example", "PDF")

I have no problem with this api addition.. could you make it and the
postgre one also please?... 

There is a good reason why the api is the way it is... rlib allows for
report concatination.. and multiple datasources... so.. you could have
rlib make 2 reports (in one).. that one of them came from a mysql
server.. the other from postgresql.. or from two seperate mysql servers
(load balancing.. hint hint)

There are also times when you need more then one query on a report...
like say you want the report title to come from a database.. or you want
to put customer information on top of the report... you can pass in
extra queries to the report.. like

	rlib_add_query_as(r, "local_mysql", "select * from example",
"example");
	rlib_add_query_as(r, "local_mysql", "select * from report_names where
report_num = 19", "report_name");

NOW.. in the XML for the main columns you have simply reference fields
by their name.. but in the report header you get the information from
report names by: report_name.name


Take a look at this example to see what I mean (for multiple reports)

	r = rlib_init();
	rlib_add_datasource_mysql(r, "local_mysql", hostname, username,
password, database);
	rlib_add_query_as(r, "local_mysql", "select * from example",
"example");
	rlib_add_query_as(r, "local_mysql", "select * from example order by
name", "example2");
	rlib_add_query_as(r, "local_mysql", "select * from example",
"example3");
	rlib_add_report(r, "report.xml", NULL);
	rlib_add_report(r, "report.xml", "example2");
	rlib_add_report(r, "report2.xml", "example3");
	rlib_set_output_format(r, RLIB_FORMAT_PDF);
	rlib_execute(r);
	rlib_spool(r);
	rlib_free(r);

- Bob

> 
> that gets rid of the need to keep an object around, and thus worrying about freeing memory.  Memory leaking is probably my biggest worry about embedding rlib in another language, so wrapping the entire report request in a single stateless call gets rid of that.  Also, I've noticed that the biggest problem people have with getting rlib to work is with the various api calls. Making this "short form" call the one most people (at least initially) use would solve that.  I can, of course, write this call for you if you like, but it's a trivial piece of C.
> 
> -john
> 
> 
> 
> > #!/usr/bin/python2.2
> 
> > import librlib;
> 
> > test = librlib.rlib_init();
> > res = librlib.rlib_add_datasource_mysql(test, "mysql", "localhost",
> > "user", "password", "database");
> > librlib.rlib_add_query_as(test, "mysql", "select * from example",
> > "example");
> > librlib.rlib_add_report(test, "report.xml", "");
> > librlib.rlib_set_output_format_from_text(test, "PDF");
> > librlib.rlib_execute(test);
> > librlib.rlib_spool(test);
> > librlib.rlib_free(test);
> 
> > - bob
> 
> > On Tue, 2003-11-04 at 19:02, John Buckman wrote:
> > > > swig looks really nice...  I wish I saw that earlier... I'll go swig
> > > > instead... so that way we can have tons of bindings ;)
> > > 
> > > Yeah, I was one of the early developers on it, years and years ago.  Once you define
> > the C bindings, it'll do everything else for you. The only caveat is that it doesn't
> > make crash-proof APIs (ie, no real parameter checking) but for rlib, that should be
> > fine.
> > > 
> 
>