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

[Paweł Cesar Sanjuan Szklarz <paweld2 gmail com>]

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.

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

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



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

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

Thanks.

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