This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Xalan ODBC extension - implementation
- From: "Hunsberger, Peter" <Peter dot Hunsberger at stjude dot org>
- To: "'xsl-list at lists dot mulberrytech dot com'" <xsl-list at lists dot mulberrytech dot com>
- Date: Tue, 22 Jan 2002 08:30:30 -0600
- Subject: RE: [xsl] Xalan ODBC extension - implementation
- Reply-to: xsl-list at lists dot mulberrytech dot com
I assume you're familiar with the Xalan extensions?
http://xml.apache.org/xalan-j/extensionslib.html#sql
It might be nice to abstract the returned result set a tad more, or to
return a result set in multiple ways depending on the application.
For our purposes, I have an extension that returns multiple results using
the HTML table model: each row in its own "tr" tag, and each column is in
its own "td". It's actually a bit more complicated than that, since I allow
the user to define an input template that can specify whether multiple
columns are to be smashed together (into one td) and any other HTML like
formatting (such as center)...
-----Original Message-----
From: Curtis Burisch [mailto:burisch@clara.co.uk]
Sent: Tuesday, January 22, 2002 5:58 AM
To: xsl-list@lists.mulberrytech.com
Subject: [xsl] Xalan ODBC extension - implementation
Hi,
At my company are implementing an extension function to Xalan which
queries an ODBC database. An SQL string is passed in, and the result
set is returned. We are still in the process of defining how the result
set will be returned.
When one row, one column (i.e. a single value) is returned, there is no
problem. However, when multiple rows & columns are returned, I am
unsure how to structure the data returned, or if indeed this is the
right way to be going about the problem.
Our plan at the moment is to return an xml fragment, something like:
<Record>
<Field name="fred">test1</Field>
<Field name="joe">test2</Field>
</Record>
<Record>
<Field name="fred">test3</Field>
<Field name="joe">test4</Field>
</Record>
Now, obviously this would be returned as a string and won't be parsed
into a tree fragment, and thus can't be interpreted by Xalan -- is
there any way to do it?
It's also highly possible that we're re-inventing the wheel. Has
anybody heard of or used an extension which would meet our requirements?
Many thanks for your time!
Best regards,
Curtis Burisch.
--
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list