I don't smoke a pipe. But more importantly, I got NO NO NO. That's basically the test I tried before posting my response - I didn't know whether it would work or not. I'm running CF 9 on Windows x64, full JRun install.

I'm not sure I'm convinced this is a sensible feature of fileExists(). Well it mostly seems OK, but something about it doesn't quite sit right for me. I guess it's because the operations to implement the "file system" side of things is completely different to that for checking URLs. And if I found myself writing a function which had two completely separate bits either side of an "else" statement, I'd start wondering if I was putting too much into the function.

What does it do with 30x responses? Also, does it do a HEAD request, or a full GET? I presume it's the latter.

Wouldn't it be nice if Adobe kept their docs up to date? Surely if someone had a ticket raised to "add this functionality to fileExists()", there should have also been a ticket to "update the documentation for fileExists()".

Personally I think I would have preferred a urlExists() function, if they were going to do this.

Still: bottom line is that it'll be handy for some people, so it's a good thing.

Also, does it do a HEAD request, or a full GET? I presume it's the latter.

HEAD, although some servers treat that as a GET.

Wouldn't it be nice if Adobe kept their docs up to date? Surely if someone had a ticket raised to "add this functionality to fileExists()", there should have also been a ticket to "update the documentation for fileExists()".

Well, good and thorough work from many people there, from which I think we can conclude:

"Don't use functions for things they weren't intended"

Personally I'd be sticking to the cfhttp suggested in the first post. Couldn't agree more with Adam though, that the inappropriately named "livedocs" should possibly be renamed as Adobe MoribundDocs. Very frustrating not having up-to-date documentation when it's needed.

Oh absolutely I see the point in testing, but doesn't fileExists(url) feel wrong to you? An url is *not* a file, the two are completely different things. If what we're saying is that a function urlExists would be handy, then surely that's just a cfhttp with a <cfreturn cfhttp.statuscode EQ 200 /> at the end?

Oh absolutely I see the point in testing, but doesn't fileExists(url) feel wrong to you? An url is *not* a file, the two are completely different things. If what we're saying is that a function urlExists would be handy, then surely that's just a cfhttp with a <cfreturn cfhttp.statuscode EQ 200 /> at the end?

O.

FileExists(url) feels perfectly right to me! In fact, in a roundabout way, File(url) already exists in ColdFusion, by virtue of java.io.File(java.net.URI)

To me it makes no more sense than having arraySort(queryset). ColdFusion is meant to be an easy-to-use development tool which is largely self-documenting due to the sensible naming of its functions.

If you called fileExists("http://www.google.com"), what file is it actually testing? Because there's no filename in there. A web request responds on port 80 with a 200 status code, but that has nothing to do with files existing.

In languages where it's the norm to have multiple function signatures I'd completely agree with you - most objects in .NET for example simply support the .sort() method. However historically that's not how CF has worked, it's been a function-based methodology with different functions for arrayClear() and structClear() for example; to change to having a clear(struct) and clear(array) methodology would be an unusual one I feel, certainly in such a loosely-typed platform.

I agree there's no harm in fileExists working on a URI, but I'd just hate to see CF go the same way of the open-source alternatives such as PHP and MySQL, where the documentation available is significantly watered down by the number of aliases that the same functions have, which've been created simply for someone's convenience.

It is ColdFusion. Here is it, in plain cfml: createobject("java","java.io.File").init(uri).

It goes without saying that, when it comes to what is Java and what is ColdFusion, the lines have been blurred since the arrival of CF MX6. The rest of your comment hangs on the line I've just discussed, so I'll leave it here.

I disagree. CreateObject is undeniably ColdFusion, but the actual object you're creating and whose logic you're using to return the result of your test is *not*, it's java. In the same way I could probably use createObject("dotnet", "system.io.File").exists(uri), but that doesn't make it CF performing the logic, it's the .NET Framework.

I understand what you say, and agree in part. I think however that, by bringing in .NET, you push the analogy too far. Coldfusion is now a Java application. Most of its new functionality is in fact composed of wrappers of Java objects.

Well no, it doesn't. You're confusing the notion of a "URL" with that of a "URI".

Also, if you read the docs @ that link you provide, it specifically states that it requires a FILE: URI. So one cannot use java.io.File to access documents via HTTP. java.io.File is for working with files on the local file system (where "local file system" could include network resources that the OS exposes as files & directories).

Well no, it doesn't. You're confusing the notion of a "URL" with that of a "URI".

Also, if you read the docs @ that link you provide, it specifically states that it requires a FILE: URI. So one cannot use java.io.File to access documents via HTTP. java.io.File is for working with files on the local file system (where "local file system" could include network resources that the OS exposes as files & directories).

--

Adam

I've just popped in, have to pop out again. Seen your e-mail come in. Just a quick acknowledgement.

I'm not confused about that, Adam. In fact, you will see that I had actually converted the argument from URL to URI.

Just to refresh my memory, I've just checked an old file transfer project involving extensive use of java.io.File(URI). And there it was indeed. But I hear what you say. It just might be a conversion from network URLs to local URIs.. I'll look in detail later and report.

Oh absolutely I see the point in testing, but doesn't fileExists(url) feel wrong to you? An url is *not* a file, the two are completely different things. If what we're saying is that a function urlExists would be handy, then surely that's just a cfhttp with a <cfreturn cfhttp.statuscode EQ 200 /> at the end?

Well no, it doesn't. You're confusing the notion of a "URL" with that of a "URI".

Also, if you read the docs @ that link you provide, it specifically states that it requires a FILE: URI. So one cannot use java.io.File to access documents via HTTP. java.io.File is for working with files on the local file system (where "local file system" could include network resources that the OS exposes as files & directories).

I will stop right here. I am wrong on java.io.File(java.net.URI). I went just one experiment too far. Like Fleischmann and Pons, and their own Cold Fusion gaffe, I cannot wriggle out of this one.

I have taken a detailed look at the code that had inspired me to think File(URI) was possible for any URI scheme. It isn't. What the code does is, get files from the web by filestreaming java.net.URL. Behind the scenes, the result is stored to disk and scheme-to-scheme converter is used to translate http:// URIs to corresponding file:// URIs. That part is not transparent, and that's what I had missed.

My apologies to you Owain. Your suggestion urlExists() indeed stands as the correct suggestion to make along these lines.

Thanks, Adam, for the correction. Sorry to have foiled the chance so early for one of our banters.