Stefan Bodewig wrote, On 03/04/2003 8.17:
On Wed, 02 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:
If I had it in jars I could ship it automatically with the jar that has the task that generated index.xml, so I can easily do something like:
<xslt in="index.xml" out="index.html" style="resource:/a/style.xsl"/>
I see. What I don't see is how we could use an URI here without breaking backwards compatibility.
In XSLTProcess we get the style parameter via setStyle(File), this obviously cannot be called with anything else but a file object. If we wanted general URIs, we'd have to change the signature and break custom tasks that inherit from or delegate to instances of XSLTProcess. No way.
I'd rather propose to add an alternative attribute styleURI or something to XSLTProcess.
What I mean is not to change the passing of a File object.
I mean that we can *wrap* an URL in a File. So we pass a File, and use an URL, getting a Virtual File System.
A File is used to open a connection, and to navigate the URI space, and a URL has the same features.
Be able to specify a URL for every task that needs a file, and that thus uses the above fileutils method.
Again, not without changing the tasks to use something else, not File, in their setter method and thus severely breaking backwards compatibility.
But if we still use File?
Or maybe KISS and just add a getStyleResource(String styleResource). It solves the immediate issue and doesn't open other potential problems.
Seems the better way to me - at least until we are prepared to break API compatibility on almost all tasks at once 8-)
If it were to break like this, I would also oppose. But could the "wrapping" ba a viable solution that easily gets us full URL usage in all file-accepting tasks?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------