On 9/20/06, Matt Benson <[EMAIL PROTECTED]> wrote:
I have been thinking it might make sense to add getURL() to Resource. Did a discussion on that already take place? I don't remember if it was generally thought to be a good idea... And, for example, what would we do for resources of nonstandard "protocols"? Would a StringResource with value "foo" return "string:foo" as its URL? Should we install custom protocol handlers for built-in resources and encourage the same be done for third-party resource implementations? Actually this sounds like a good idea to me. Because it seems to touch on the discussion we had before about a string "encoding" to allow a Resource to be specified as an attribute. We talked about whether a "type:stringconstructorarg" scheme would work... but if IH knew that setFoo(Resource r) meant to treat the attribute string as a URL and we had custom protocol handlers installed for the built-in Resource types, that would be just as good, if not better (I'm not forgetting we would have to special-case protocol-less strings to be interpreted as files for BC).
I have no opinion about adding getURL () to Resource, but I think that adding an easy way to encode/decode a resource to a string is really a must! And using a "type:" scheme is not really convenient IMHO. So using custom URL scheme sounds like a very good idea! -Xavier This sounds pretty involved. We could go ahead and
add getURL() to Resource, having it throw UnsupportedOperationException by default, or we could wait. In either case, post 1.7.0, we could run with the custom protocol handling idea. Community? -Matt > > Regards, > > Antoine > -------- Original-Nachricht -------- > Datum: Tue, 19 Sep 2006 21:58:19 -0000 > Von: [EMAIL PROTECTED] > An: [EMAIL PROTECTED] > Betreff: svn commit: r447990 - in > /ant/core/trunk/src: > etc/testcases/taskdefs/style/build.xml > main/org/apache/tools/ant/taskdefs/XSLTProcess.java > main/org/apache/tools/ant/taskdefs/optional/junit/AggregateTransformer.java > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]