tracker issue : CF-3909707

select a category, or use search below
(searches all categories and all time range)

cfwddx doesn't work in script

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/NotABug

Reporter/Name(from Bugbase): Raymond Camden / Raymond Camden (Raymond Camden)

Created: 12/15/2014

Components: Language

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Normal / Few users will encounter

Locale/System: English / Mac 10.9

Vote Count: 0

In the "all tags work in script" support, cfwddx was forgotten somehow.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3909707

External Customer Info:
External Company:  
External Customer Name: cfjedimaster
External Customer Email:  
External Test Config: My Hardware and Environment details:



We need a repro, Ray. As discussed, this works fine for me: <cfscript> cfwddx(action="cfml2wddx", input={}, output="w"); writeDump(var=variables); </cfscript> -- Adam
Comment by External U.
9395 | December 15, 2014 11:55:12 AM GMT
Yep, you are right. The entire issue was that I did: x = cfwddx(action="cfml2wddx", input="something") the x= must have confused the parser. I do think the error should have been clearer though. At worst, shouldn't it have worked, but X simply be undefined?
Comment by External U.
9396 | December 15, 2014 12:02:50 PM GMT
I wish the tag-to-script functions actually returned results w/o having to pass the result name as a parameter. Thanks!, -Aaron
Comment by External U.
9397 | January 06, 2015 04:52:13 AM GMT
Well, Aaron, a few other things to consider first: a) accept that tag-based code is entirely different in design to script-based code; b) don't simply implement tags with no angle brackets and go "look! 100% script coverage!" (because that just makes Adobe look like lazy, clueless oiks); c) don't prefix everythig with "CF". WE GET IT, IT'S CFML. No other bloody language prefixes its constructs with the vendor name!!! What the hell is wrong with you people? d) do the work properly, and implement the functionality for CFScript *properly* and like professionals. *Then* we get to: e) yeah, something that looks like a function should return a value, not expect one to pass a string in which is then magically used to create an undeclared variable in the calling code.
Comment by External U.
9398 | January 06, 2015 05:23:36 AM GMT
Hi Adam, The "CF" prefixing always had me thinking about something. I've always wanted to create my own built-in-functions. Currently, I avoid any future naming conflict by prefixing my UDF names w/ "udf" (ex: udfIsFoo()). But it'd be sorta neat to be able to create my own "isFoo()" function too. If CF ever allows us to extend the language w/ our own true BIFs, hopefully our isFoo() would trump CF's isFoo(). If CF is insistent on trumping our BIFs w/ its own BIFs, then the "CF" prefixing may come in handy there. But surely CF would allow our BIFs to trump its own? In that case, I'm sure the "CF" prefixing could just be done away with. Thanks!, -Aaron
Comment by External U.
9399 | January 06, 2015 06:14:33 PM GMT
Hi Adam, Looking at the "CF" prefix from another angle, it looks like there'd possibly have been some naming conflicts if the "CF" prefix hadn't been used: BIF vs tag-to-script ---------------------------------- fileupload() vs fileupload() insert() vs insert() invoke() vs invoke() location() vs location() log() vs log() throw() vs throw() trace() vs trace() Since location(), throw() and trace() all accept named parameters identical to their tag counterpart, it appears there'd have been no issue w/ these. Well, except for the trace() BIF not properly supporting a body (#CF-3811003). fileUpload() could've been resolved by allowing the BIF to accept named parameters. invoke() doesn't transiently instantiate a web service object (#CF-3864527), nor does it support a body (thus doesn't support an invokeargument() (#CF-3863516)) - so <cfinvoke> would've probably had to have been named something other than invoke(). insert() and <cfinsert> differ, as does log() and <cflog>, so <cfinsert> would've had to have been named something other than insert() and <cflog> would've probably had to have been named something other than log(). Just thought I'd check to see what might've conflicted. Thanks!, -Aaron
Comment by External U.
9400 | January 06, 2015 07:19:36 PM GMT
Please disregard the "<cflog> would've probably had to have been named something other than log()" b/c writeLog() already exists.
Comment by External U.
9401 | January 06, 2015 07:23:22 PM GMT
In short, it looks like the "CF" prefix could've been avoided if: 1) trace() properly supported a body 2) invoke() could transiently instantiate a web service object and supported an invokeargument() 3) <cfinsert> and <cfupdate> became something like dbInsert() and dbUpdate() Thanks!, -Aaron
Comment by External U.
9402 | January 06, 2015 07:28:02 PM GMT
Geez.. forgot about the <cfdirectory action="list"> vs directoryList() issue. :/
Comment by External U.
9403 | January 06, 2015 07:29:18 PM GMT