[EMAIL PROTECTED] wrote: > XSLT Extensions assist formatting. Data collection belongs in the XML > generation phase. Using XSLT Extensions to generate data is a very > bad practice. What are the requirements?
Let me explain better. I need to translate URIs in a XML document, in the middle of a pipeline, fetching relevant information from a SQL database. "In the middle of a pipeline" means that there are various other steps before it, so I cannot fetch this SQL data in the initial generator. At first I tried to have a sub-pipeline do the job, using the document() XPath function with a cocoon: schema, but it was too slow. My next (and current) idea is transforming the XML with XSLT, while coding the actual URI transformations (including the SQL queries) as a Java extension function, to be called from XSLT where appropriate. I'm hitting a wall, because I need a DataSourceComponent to be able to make SQL queries, but a Java XSLT extension class doesn't have any access to Cocoon's object model (that I can see.) I cannot pass the DataSourceComponent, or any other interesting object, from the sitemap to my extension function, passing through the XSLT as a parameter, because XSLT parameters get passed from the sitemap as strings. Suggestions are welcome. My last resort is doing everything as a custom transformer, but I'd like to avoid it, as I'm not too keen on coding in Sax what can easily be dealt with in XSLT (changing a bunch of attribute values.) Although it wouldn't be too hard with Sax either... Tobia --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
