On Thu, Oct 16, 2008 at 1:48 PM, Robert Koberg <[EMAIL PROTECTED]> wrote: > > Actually, there is more. You will want to check all document functions to > see what other is being used and if it has changed. I actually have > something like that, but it works off a hierarchical config file (something > like what apache forrest uses but more recursive in orientation) that is not > really.
Ah ah, indeed, I didn't think about doc() calls. But aren't these dependent on variables, and the primary XML document's content possibly, while the import/include must use URLs only, possibly dependent on params only? I'm no expert at XSLs, but just dealing with import/include would already be an improvement. > Instead of parsing the XSL, I use 2 custom URIResolvers to gather the > dependent files and put that into a cache entry object. This is smart! you're intercepting the calls to discover which resources are used. You must then keep a cache in the filesystem then though. (there's already a cache impl linked to <uptodate> I think). While you're at it, why not find out which result document(s) were generated, especially is XSLT 2.0 where it's no longer an extension and part of the language? Just kidding, <javac> doesn't compile a file if the generated .class for an inner class are been removed, that's the same kind of limitation. Thanks for the precision Rob. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
