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="[EMAIL PROTECTED]'type']/text()"/> </xsl:attribute> <ae:tag> <xsl:value-of select="[EMAIL PROTECTED]'tag']/text()"/> </ae:tag> <ae:value> <xsl:value-of select="[EMAIL PROTECTED]'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) > 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 _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
