On 9/11/07, Paweł Cesar Sanjuan Szklarz <[EMAIL PROTECTED]> 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="[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. 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 _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
