Henry asks:
Does CF9 script style CFC still needs to set attribute output=false for component and function?
In my - admittedly - very limited testing, the answer appears to be no. I created a component with a large amount of white space in both the function and around it as well:
component {
public string function sayHello() {
return "Hello World!";
}
}
I duplicated this component but added output="false" to both the component and method:
component output="false" {
public string function sayHello() output="false" {
return "Hello World!";
}
}
To test then I created an instance of both and wrapped the sayHello call:
<cfset badWS = new testws()>
<cfset goodWS = new testws2()>
<cfoutput>
Testing bad: -#badWS.sayHello()#-<br/>
Testing good: -#goodWS.sayHello()#-<br/>
</cfoutput>
The result was the exact same. No additional white space from the creation of the CFC or the call either. I even tested making an instance of the first CFC with createObject, just to see if it made a difference, and it did not. Of course, it isn't like the output="false" argument is ignored. If you write a CFC method that outputs directly to the screen, then it does matter. Consider:
public function sayHello2() { writeOutput("hello2!"); }
That function will work just fine, but if you modify it a bit...
public function sayHello2() output="false" { writeOutput("hello2!"); }
Now you have a useless function. The output="false" will suppress the writeOutput>
Archived Comments
My opinion on this new scripting stuff is so torn, on the one hand I think it's really cool, makes the language feel somewhat more grown-up or something, I don't quite know, but on the other hand the reason I first started using CF was because of the tag based nature and how intuitive it felt as someone who has only previously dealt with html.
Tags have there place on the presentation layer. To me it just feels better writing business logic in a less verbose more natural environment. The great thing is though developers have a choice so if its not for you don't worry, continue writing code the way you do now!
I'll ditto Dan. If the script stuff doesn't work for you, don't use it. :)
The reason you get no extra whitespace using script-based CFCs is this: The only way a script block can output to the buffer is using writeOutput()... so if you have an all-script CFC, you won't get any whitespace. If you have a template with cfscript tags, you'll get the whitespace outside the cfscript tag, but you won't get any whitespace from the code _inside_ the script tag.
Re: White Space
Interesting.
In CFAdmin what is your 'Enable Whitespace Management' set to? By default in CF9 its now checked and I wonder if that changes things.
Re: Script and Tags
We've got the best of both worlds now :)
Good catch there. I forgot that in CF9 this is turned on by default. I turned it off, but it didn't impact anything.
@Jared: Yeah, I believe you are 100% right, and it is kind of obvious now, but at the same time, good to confirm.
I tend to be anal about output="false" in my CFCs, but won't be bothering with it when i do script based ones.
I don't believe that the whitespace management setting in the CF Admin should have any effect on script... script can't just output text unless you tell it to by using writeOutput() . Whitespace management is an artifact of a tag-based world built exclusively to output to the browser and extended to build objects.
Ooops, I said that already. Heh.
I cannot get teh brainz to fully engage today. ;)
Thank you for answering my question, jedi! :D
This is pretty much the behavior I would expect from a script-based CFC, but it's certainly nice to see it actually tried out and confirmed.
Does anyone know if it's possible to call custom tags using script-based syntax? If so, I wonder what would happen then.
Thanks!
You can't. If your custom tag didn't need to support children, or wrapping, it would take two seconds to wrap cfmodule into a UDF. This would allow you to do: module("foo.cfm",{arg1=x,arg2=y}).
Well, maybe not two seconds. ;) It would be difficult to tell if the tag returned a value that you would then pass back. However, if you want to replace a _known_ custom tag call, then you could definitely write a quick UDF wrapper for it.
G'day
Just on the whitespace thing. There's still a slight use case for specifying output=false on script-based functions & components.
If the script code includes a tag-based file, the whitespace from the tag-based file still outputs (if whitespace management is off, natch).
It'd be questionable form to be including files from within a function, but it's still possible, so maybe worthwhile tucking this thought away in the corner of ones brain.
--
Adam
@Adam: Wow, good find there. Thank yoU!
Hey Adam, good call. I can see that being an important function in a framework or DSL intended to process files into output, for example, and it would be perfectly fine in that case. I mean, there are probably a 100 places where this.include("/template/path.cfm") would be a viable method call, and in that case you have a totally valid point. :)