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