Couple more little glitches as the app has continued to be tested:
1)
I mistyped 'reqeustTimeout' [sic] in a CFSETTING tag. BD didn't
complain, and I didn't catch it, because the extra time for the request
never happened to be needed, but CF threw a syntax error immediately.
2)
BD 6.2 puts the CFFILE result struct from uploads into local variable
(if declared), inside functions. I was never quite sure what CFMX 6 did
regarding this. CF7, however, puts it in some unknown place
(presumably variables scope) that is shadowed by the local variable
scope. Just a matter of adding the new CF7 'result' attribute to
name the value you want the result placed in. I think this is
actually a bug in CF7 (breaking backwards compatibility), but I'm not
sure about that. Either way, it is a difference between BD and CF
that you should watch out for.
I'm not sure if you've ever seen this…
But I have a CFC that displays a small block of HTML.
var = "The string"
In CF6.1 (sorry, I don't yet have access to 7 :-(… ) if you have a variable to display #var# will show as "The string".
While in BD 6.2, #var# in the CFC shows "#var#". I've had to add cfoutput tags so that the vars will display the dynamic content.
Have you seen anything like this?
Are you using the 'output' attribute of CFFUNCTION? If not, you should. I can't speak for BD, but on CFMX (all versions, I believe) the 'output' attribute has three states: true, false, and missing. True means the body of the function should be displayed as if wrapped in a CFOUTPUT tag. False means the body shouldn't display anything as if wrapped in a CFSILENT tag. A missing 'output' attribute means the body should be displayed like any other inline content.
It's possible (likely, even, from what you describe) that a true value on BD means the same as a missing value on CFMX (display the body, but don't act as if it's in a CFOUTPUT block). I very rarely output anything inside CFCs (preferring to return the content as a string), so I can't speak for this discrepancy.
Actually…
After leafing through some more google results….
It's in the docs..
From the compatibility guide:
"4.2.3 CFCOMPONENT
When setting the attribute OUTPUT=”yes”, BlueDragon requires you to enclose all CFML
expressions (#expression#) in CFOUTPUT tags, where CFMX will evaluate CFML
expressions without requiring CFOUTPUT tags."
"4.2.7 CFFUNCTION
When setting the attribute OUTPUT=”yes”, BlueDragon requires you to enclose all CFML
expressions (#expression#) in CFOUTPUT tags, where CFMX will evaluate CFML
expressions without requiring CFOUTPUT tags."
I guess that is why.
;-)