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 14:33 +0200, Vivien Malerba napisał(a):
>
> > 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).
>
> Maybe not directly a DSN, but some similar feature can be usefull.
> If you can declare the connection in the xsl template, then it is
> posible to make a program like xsltproc to test the xslt-sql templates
> without any additional C code.

I agree with this but it means someone has to store username and
password in the XSL file... You can implement this if you need it
(maybe with a warning about how unsecure it is to store a password in
the XSL file).

>
> >
> > 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,
>
> For my is OK. I will do so.
>
> >  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.
>
> I thing that one attribute is better:
> <sql:query cncId="cnc2"..>..</sql:query>
> <sql:query cncId="dict"..>..</sql:query>
> and in the code, check what type we have.
> It is because in a possible XSD you will have one obligatory attribute
> and not 2 optionals.

Ok, no problem.

>
> >
> > >
> > > 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?
>
> I check the Documentation and I thing that:
> (i will check the later code, to be sure all this is true)
>
> <gda_report_section> and
> <gda_report_query> :
>
> This is a better idea that the actual sql:query, because you are inside
> the gda_report_section when use the SQL results.
> I can make a element like this:
> <sql:gda_section>
>   <!-- the @query_name is optional-->
>   <sql:gda_report_query query_name="customers">
>     SOME SQL
>   </sql:gda_report_query>
>   <sql:section_template>
>     <!-- usual xsl information-->
>   </sql:section_template>
> </sql:gda_section>
>
> I propose make gda_report_query obligatory and put there the attribut
> @query_name, to make a XSD schema for the extension easier to write.
> The xslt procesor will work normally inside sql:section_template, and
> only there will be the query result accesible.
>
> <gda_report_iter> :
>
> With the actual function sql:getnodeset you can get a node set from the
> Data_model, and then build whatever you want, like here:
>
> <!-- create node set from results -->
> <xsl:variable name="nodeset_tags" select="sql:getnodeset('tags')"/>
> <!-- fast debug posibility, want to see the raw results then just
> uncomment the debug node -->
> <!--
> <ae:debug>
> <xsl:copy-of select="$nodeset_tags"/>
> </ae:debug>
>  -->
> <!-- iteration on the nodeset: -->
> <!-- for-each row -->
> <xsl:for-each select="$nodeset_tags/row">
>
> <ae:userTag>
> <xsl:attribute name="type">
> <!-- here we get the value of the column type -->
>         <xsl:value-of select="column[ name='type']/text()"/>
> </xsl:attribute>
> <ae:tag>
>         <xsl:value-of select="column[ name='tag']/text()"/>
> </ae:tag>
> <ae:value>
>         <xsl:value-of select="column[ name='value']/text()"/>
> </ae:value>
> </ae:userTag>
>
> </xsl:for-each>
>
> it is posible to make more complicated iteration:
> <!-- for-each row, where the tag column value is iqual 'test' -->
> <xsl:for-each select="$nodeset_tags/row[column/type/@tag='test']">
> .....
>
>
>
> <gda_report_param_value>:
> this is done with
> sql:getvalue
>
>
> <gda_report_if>, <gda_report_if_true> and <gda_report_if_false>:
>
> you can set a xsl:variable to some value, and then make some logic:
> <xsl:variable name="subject"
> select="sql:getvalue('tenders','subject')"/>
> <xsl:if test="string-length($subject) &gt; 0">
> .......
> </xsl:if>
>
> If there are some SQL expresion that cant be evaluated on xslt, then we
> can make this extension function
> sql:checkIf('resultSetName','Any_sql_condition').
> returning boolean values.

Ok for me with all of your proposals.

>
>
>
> >
> > >
> > > !!!!!!!!
> > > 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).
>
> I will do.

Ok.

Also, if you agree, I'll add your code as part of the libgda-report
library as your extension and the reports feature are quite close. I
propose you send me some code for inclusion when you have finished.

Thanks a lot,

Vivien