Ask a Jedi: Impact of whitespace and script based CFCs

This post is more than 2 years old.

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>

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Robert Rawlins posted on 8/26/2009 at 5:00 PM

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.

Comment 2 by Dan Vega posted on 8/26/2009 at 5:04 PM

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!

Comment 3 by Raymond Camden posted on 8/26/2009 at 5:18 PM

I'll ditto Dan. If the script stuff doesn't work for you, don't use it. :)

Comment 4 by Jared Rypka-Hauer posted on 8/26/2009 at 6:27 PM

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.

Comment 5 by sam Farmer posted on 8/26/2009 at 6:36 PM

Re: White Space


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 :)

Comment 6 by Raymond Camden posted on 8/26/2009 at 6:41 PM

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.

Comment 7 by Jared Rypka-Hauer posted on 8/26/2009 at 7:10 PM

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.

Comment 8 by Jared Rypka-Hauer posted on 8/26/2009 at 7:12 PM

Ooops, I said that already. Heh.

I cannot get teh brainz to fully engage today. ;)

Comment 9 by Henry Ho posted on 8/26/2009 at 9:59 PM

Thank you for answering my question, jedi! :D

Comment 10 by Jose Galdamez posted on 8/26/2009 at 11:38 PM

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.


Comment 11 by Raymond Camden posted on 8/26/2009 at 11:41 PM

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}).

Comment 12 by Raymond Camden posted on 8/26/2009 at 11:45 PM

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.

Comment 13 by Adam Cameron posted on 8/29/2009 at 10:05 AM

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.


Comment 14 by Raymond Camden posted on 8/29/2009 at 5:41 PM

@Adam: Wow, good find there. Thank yoU!

Comment 15 by Jared Rypka-Hauer posted on 8/29/2009 at 6:14 PM

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. :)