Re: [gnome-db] sql extension to libxslt using libgda.

["Vivien Malerba" <vmalerba gmail com>]

On 9/11/07, Paweł Cesar Sanjuan Szklarz <paweld2 gmail com> wrote:
> Hi.
>
> Dnia 11-09-2007, wto o godzinie 11:45 +0200, Vivien Malerba napisał(a):
> > This is an interresting piece of work. Tell me if I'm wrong (I'm no
> > XSLT expert), but here is how I understand it: the code you show here
> > is an extension which can be used with the libxslt library, declared
> > as such to the libxslt library (using xsltRegisterExtModule()).
>
> Yes.
> Libxslt dont have dinamical load of libraries for the extensions, so the
> code that calls xsltRegisterExtModule() have to be access to the
> extension init/finalize functions (of course,when linking the code).
>
> >
> > As you might expect, I have a few questions/remarks:
> > * (not strictly related to your code) is it related to libxslt or to
> > Libexslt (http://xmlsoft.org/XSLT/EXSLT/index.html)?
> This extension use only libxslt. libexslt use the same api that I am
> using.
>
> The diference with libexslt and my extension, is that the extensions
> from libexslt are alreally declared on libxslt.

Ok, thanks for the explanation.

>
> > * how should libgda make that extension available (if the libxslt
> > framework is generic enough, I would prefer not add some extra API
> > such as sqlxslt_process_xslt_file_ext(), to rely as much as possible
> > to libxslt's own API)?
> sqlxslt_process_xslt_file_ext() is just a test function, it can be drop
> from the library.
>
> >  Would it be possible for example to have only 2
> > calls like:
> >    xsltTransformContextPtr *gda_xslt_create_context (GdaConnection *cnc)
> >    xsltTransformContextPtr *gda_xslt_create_context_with_dict (GdaDict *dict)
> >   and then let the user use that transform context as he would for any
> > other tranform context?
>  The API from libgda depends on what extension elements and functions
> you want to have.
> For example, it is posible to have a sql:configuration node like this:
> <xsl:template match="/">
> <sql:configuration>
>   <sql:dns>dnstest</sql:dns>
> </sql:configuration>
> .........
> </xsl:template>
> that set the database configuration inside the
> XSLTTransformationContext.
> Then you just need from libgda a function like this:
>    void gda_xslt_register_sql_extension(GError **error);

I don't really like the idea of specifying a DSN (BTW it's DSN as data
source name and not DNS) because
then you need to declare a DSN which sometimes you may not want (you
can use a connection string instead).

Also someone might want to use more than one connection at a time to
fetch data from several sources, so I suggest that each time a query
is run, a named connection should be used (just a GdaConnection
identified as a string).

So here is the API I propose (one single call):
xsltTransformContextPtr *gda_xslt_create_context_simple (GdaConnection
*cnc, GError **error);
and
xsltTransformContextPtr *gda_xslt_create_context (GError **error, ...)
where the ... part is a NULL terminated list of (GdaConnection or
GdaDict, name) couples, as for example (in a hypotetic example where I
would use 2 connections and a dictionary):

my_cnc1 = ...
my_cnc2 = ...
my_dict = ...
GError *error = NULL;
my_context = gda_xslt_create_context (&error, my_cnc1, "cnc1",
my_cnc2, "cnc2", my_dict, "dict", NULL);
[...]
xsltFreeTransformContext (my_context);

and in the XSL file I would have
<sql:query cnc="cnc2"...>...</sql:query>to refer to cnc2, or
<sql:query dict="dict"...>...</sql:query> to refer to the connection
associated to dict.

>
> The real question about a API from libgda is:
> What elements and functions extension we want to implement??

The ones you proposed seem to be a good starting point (as it fulfills
your needs).

Also, you may want to have a look at the new report engine which also
transforms an XML file when it encounters some special nodes (it
operates on the DOM representation of the XML file and
adds/changes/removes XML nodes), see
http://malerbavintner.free.fr/doc/3.2.x/libgda-3.0/GdaReportEngine.html.

Do you think it would be possible to have the same kind of tags?

>
> !!!!!!!!
> Each elem/func extension needs a backend function on libgda.
> !!!!!!!!
>
> Maybe a <sql:command> to run GdaCommand queries.
> <sql:configuration>???
> <sql:transaction>??

I think we really should limit this to SELECT queries, I see no point
in running non SELECT queries in an XSL transformation (anyway for an
initial impementation).

>
> Now only results from GdaQuery that are gda_data_model's are used.
>
> > * for now the code depends on log4c, that dependency would have to be dropped
> Sure.
> For web applications I use log4c. If the extension will be in libgda,
> then a GError on the output is enough.

Ok.

>
> > * the gda_value_stringify() calls can easily be replaced by other
> > calls, I can help there!
> It is my first code with libgda, so I just get the easy way. I will be
> grateful for any help.

See the value_to_node()'s implementation in the gda-report-engine.c file
in libgda-report/engine.

>
> > * Would you agree to licence your code under the LGPL as all libgda is licenced?
> Yes, no problem.
>

Ok, thanks.

Vivien