ColdFusion 11: cfclient seems to require /CFIDE to be available

Question

G'day:
I am reposting this from my blog ("ColdFusion 11: <cfclient> seems to require /CFIDE to be available") at the suggestion of Adobe support:
@dacCfml @ColdFusion Can you post your queries at http://t.co/8UF4uCajTC for all cfclient and mobile queries.— Anit Kumar Panda (@anitkumar85) April 29, 2014
I have edited this in places to remove language that will be deemed inappropriate by the censors here. Changes I have made are in [square brackets]. The forums software here has broken some of the styling, but so be it.
G'day:
This will be a short one... I just want to trot out various observations I make about <cfclient> as I make them. I don't want to waste too much effort on it.
I also feel a bit dirty round about now... I'm about to use a <cfform> tag.
As should everyone, I do not expose /CFIDE to the outside world. This is a terrible vector for security vulnerabilities. One that Adobe seems to be dragging its heels about resolving once and for all ("Isolate the /CFIDE/scripts directory from the rest of /CFIDE" (3732913)).
So when I'm using <cfform> (which is only ever when I am writing example code like this), I need to redirect ColdFusion to look in my isolated directory which just has the script stuff in it:
<cfajaximport scriptsrc="/lib/js/CF/scripts"> <cfform method="post" action="#CGI.script_name#">     <cfinput type="dateField" name="date">     <input type="submit" name="submitButton" value="Go"> </cfform> <cfdump var="#form#">
Note: do not use <cfform> or any of ColdFusion's other UI wizard tags. Just don't. See here: "ColdFusion UI the Right Way", here: "I'm not going to tell you to stop using ColdFusion UI tags anymore...", and here: "Oi! You [naughty] [people]! Stop using ColdFusion UI controls".
Anyway, back to the code. The poorly-named <cfajaximport> tag allows one to point ColdFusion at a different, isolated directory. That's quite handy.
Now I try it with my <cfclient> code:
<cfajaximport scriptsrc="/lib/js/CF/scripts"> <cfclient> <cfset message = "G'day World"> <cfoutput>#message#</cfoutput> </cfclient>
and I get this:
14:46:11.292
GET
http://localhost:8511 /shared/scratch/blogExamples/coldfusion
/CF11/cfclient/moveScriptDir.cfm
[HTTP/1.1 200 OK 284ms]
14:46:11.655
GET
http://localhost:8511 /lib/js/CF/scripts/ajax/messages/cfmessage.js
[HTTP/1.1 200 OK 5ms]
14:46:11.655
GET
http://localhost:8511 /lib/js/CF/scripts/ajax/package/cfajax.js
[HTTP/1.1 200 OK 10ms]
14:46:11.656
GET
http://localhost:8511/CFIDE/cfclient/cfclient_main.js
[HTTP/1.1 404 /CFIDE/cfclient/cfclient_main.js 3ms]
14:46:11.656
GET
http://localhost:8511/CFIDE/cfclient/cffunctions.js
[HTTP/1.1 404 /CFIDE/cfclient/cffunctions.js 3ms]
14:46:11.657
GET
http://localhost:8511/CFIDE/cfclient/cfclient_main.js
[HTTP/1.1 404 /CFIDE/cfclient/cfclient_main.js 1ms]
14:46:11.657
GET
http://localhost:8511/CFIDE/cfclient/cffunctions.js
[HTTP/1.1 404 /CFIDE/cfclient/cffunctions.js 0ms]
Groan. Because <cfclient> doesn't put its script files in the scripts dir, does it? No. Of course it doesn't. Muppets.
But this could still be solved if one could specify some other way of pointing it to a different location for its resources, but... no. There's not a way of doing this that I can find. Short of [messing] around on the web server and setting up virtual directories pointing to /CFIDE/cfclient. This isn't really a hardship, but still, it just shouldn't be necessary, and I can't help but think this is a bit sloppy on the part of Adobe.
It also demonstrates that for their internal testing they don't test this sort of thing. Which is odd, as it's the second thing I tested: you know, that it even works on a secured server.
That's it. I've nothing else to say on this topic. I'll raise a bug for this shortly, once I have the article published so I can refer back to it: 3750729.
Adam

Answer 1

The functions defined in the cffunctions.js are not namespaced. If it is namespaced, you would have to add the namespace while using a function inside cfclient.
These functions are not namespaced, so that you can use the same syntax for using a function inside and outside the cfclient block.
This is indicative of everyone's concern that you guys would just implement / encourage poor practice in your <cfclient> implementation.
How is it - given you're "compiling" the CFML anyway - you cannot translate source code that says "listlen()" into "compiled" JS that is CF.listLen() or something? Thus good CFML can be translated into good JS.
You seem to think that there's a one-to-one mapping between what the CFML says and what the resultant JS needs to be.
You've basically written a mechanism for a CFML developer to write bad JavaScript.
Well done.
Adam