John, In java.sql.Statement we have executeQuery(String sql) and executeUpdate(String sql). executeQuery() is called by the Xalan XStatement constructor, called in turn when the XSLT extension function sql:query() is called. My original idea was to just implement update queries as calls to Statement.executeUpdate(String sql), adding an sql:update() extension function to the XSLT. The problem is doing it without breaking the existing API, I suppose. One might subclass XStatement with XUpdateStatement. However, since the ResultSet return type of Statement.executeQuery() is more complex than the int return type of Statement.executeUpdate(), maybe the object representing an update query wouldn't need to implement all the interfaces of XStatement. A subtlety of doing updates are error handling, and also transaction control (commit and roll back.) Perhaps we would want to add transaction control functions to the extension as well. I take it XMLDB is an unpublished project right now? Where could I read about it? If we can come up with a overall gameplan to the level of a rough API I'd be happy to go about coding a sample implementation. Right now I'm building my servlet request parameters into a DOM, in a servlet filter. Then I optionally transform with Xalan, and attach the DOM to the servlet request. The actual servlet currently identity-transforms this (possibly transformed) request DOM back to the servlet response. Back in the servlet filter, I search the response for associated stylesheet reference, and tranform if I find one. I have found that I can mock up a working model of all of my business logic for the various forms of my web application using just XSLT. For instance, I can "normalize" form data into a hierarchical structure (if the input tags are named carefully to reflect the hierarchy in the otherwise flat form data.) The hierarchical request can have line items for payments as elements below the document element, each built by looking at inputs named "Amount.0, ReferenceNumber.0, Amount.1, ReferenceNumber.1" etc. 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 > --------------------------------------
