With regards to updating a database using a hypothetical
Xalan extension function set:
This is much less than the proper formal reply to doing SQL DML
(INSERT/UPDATE/DELETE) via XSLT, but it's late (been to the comedy
club with girlfriend, who's now asleep)
You make a good point about the fact that XSLT transformers may
call the templates in any order. The XSLT elements are arranged,
that is to say, collected, in an unordered tree.
However, the examples I've seen of the SQL Xalan extension library,
just doing "read-only" queries, do things like setting a variable
to a NodeSet read from an XConnection, and "then" performing an
xsl:for-each on the resulting variable. Now this is a "first this,
then, secondly, this" kind of regime. I accept that examples of
DML using XSLT extensions might look hairy ("unmaintainable",
as you said), but I want to know if the concept is not just
difficult but impossible (given good XSLT'ing practices, of
course "The Wrong Thing" should be taken as "impossible." I do
hate sloppiness, and think that designs that allow it are
to be avoided.
Since any sucession of transforms performed one at a time can
be composed (in a linear algebra) sense into a single
"ubertransformation", it follows that *some*
transforms can be decomposed into
a series of more elementary tranformations. The general difficulty of
this has the one-way character of differentiation versus integration
in calculus, and the various functions that encrypt our data.
The "s/he-man" hacker thing to do would be to want to write a
monolithic transform that does everything at once. However, I believe
that the weird design patterns required to do extension function
calls with side effects can be made to appear more simply if they
are collected into a simple transform step which concerns itself
only with that activity. Preparing the request can come before,
in a separate transformation, and formatting the response can
come after. It helps that both the request transformation and
the response transformation can perform (as things stand now)
SQL queries that can do things like assign stylesheets.
If producing a set of "update, xsl-when, commit or rollback"
templates can be done, that is to say, a reasonable design pattern
can be obtained for minimal useful examples of SQL DML within
XSLT, then it should be possible to compartmentalize this
structure in isolation from any other maintenance issues, that
is to say, within its own stylesheet. (Then the SQL geek
can maintain that, and some other geek can maintain the other
transforms, which is what I'm *really* looking to get from
XSLT in the servlet filter.... :)
Finally, without wanting to blow smoke up anyone's shorts, I'm just
thrilled with XSLT, and Xalan is the Best Thing That Uses It.
Apologies in advance if this series of postings is easily judged as
crackpot. (And I'll believe you if you convince me that's what
they are.) There used to be a sign posted at our local cave research
station: "Those of you that think you know everything are
irritating to those of us who do."
Regards,
Alan
John Gentilin wrote:
>
> Alan,
>
> We currently use Xalan for Queries and our own XMLDB Package
> to convert an XML Stream into a series of SQL operations. Currently
> I am working on the port from DOM mode to DTM mode. If you wanted
> to throw around some ideas, I am will to discuss them.
>
> Another idea we have been kicking around is submitting our XMLDB module
> as an Open Source Project. Our biggest stopping point is how much bandwidth
> will it require to support the process.
>
> What I have now is a UML Model of the extension code (using MagicDraw) and
> I plan to start the coding process this weekend. Do you have any ideas on the XSL
> code that will be used to produce the Database Updates ?? I was looking into just
> adding our XMLDB as a extension of the redirect function but the end result was
> getting ugly.
>
> Regards
> John Gentilin
>
> Alan Canon wrote:
>
> > I'm interested in doing DML from my XSLT, in order to implement all
> > of my business logic in XSLT (I can do everything but that.)
> >
> > Is support for update/insert/delete queries planned for the Xalan
> > SQL extension? I know that this could create side effects within
> > the database (that's the whole point), but so select
> > queries can do this too if a user-defined function is called
> > using the query. So adding DML capability seems like it's not
> > entirely beyond the pale.
> >
> > Need a volunteer?
>
> --
>
> --------------------------------------
> John Gentilin
> SMART911
> 18314 Carlwyn Drive
> Castro Valley CA 94546
>
> Contact Info
> [EMAIL PROTECTED]
> Phone 1-510-881-4821
> --------------------------------------
